home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Plus Special 20
/
AMIGAplus Sonderheft 20 (1999)(ICP)(DE)[!].iso
/
PublicDomain
/
Alternatives
/
LinuxAPUS
/
Docs
/
LinuxAPUS_FAQ
/
faq.sgml
< prev
next >
Wrap
SGML Document
|
1999-01-01
|
179KB
<!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
<!-- $Id: faq.sgml,v 1.64 1999/03/22 20:15:55 jskov Exp $ -->
<!ENTITY thisdoc "The &linapus; Doc'n'FAQ">
<!ENTITY linux "Linux">
<!ENTITY linapus "Linux/APUS">
<!ENTITY linm68k "Linux/m68k">
<!ENTITY linppc "Linux/PPC">
<!ENTITY cpuppc "PowerPC">
<!ENTITY cpum68k "MC68k">
<!ENTITY cpu040 "MC68040">
<!ENTITY cpu060 "MC68060">
<!ENTITY cpu603 "PPC603p">
<!ENTITY cpu604 "PPC604">
<!ENTITY sunsite "SunSITE Denmark">
<!ENTITY gvp "GVP">
<!ENTITY p5 "Phase5">
<!ENTITY pup "PowerUp">
<!ENTITY blzppc "Blizzard/PPC">
<!ENTITY cybppc "CyberStorm/PPC">
<!ENTITY gdb "<application>GDB</application>">
<!ENTITY x "<application>X</application>">
<!ENTITY dmesg "<application>dmesg</application>">
<!ENTITY boothack "<application>boothack</application>">
<!ENTITY amiboot "<application>amiboot</application>">
<!ENTITY rh "RedHat">
<!ENTITY rpm "RPM">
<!ENTITY rhinstaller "RedHat Installer">
<!ENTITY rhppc "RedHat/PPC">
<!ENTITY rhrc "RedHat/Rough Cuts">
<!ENTITY debian "Debian">
<!ENTITY debppc "Debian/PPC">
<!ENTITY deb "DEB">
<!ENTITY amiga "Amiga">
<!ENTITY ados "&amiga DOS">
<!ENTITY hdtbox "<application>HDToolBox</application>">
]>
<!-- TODO:
add version information
make some of the lists into tables
footnoteref only works on same page :(
-->
<book>
<bookinfo>
<date>$Date: </date>
<title>&thisdoc;</title>
<releaseinfo>documentation in progress</releaseinfo>
<authorgroup>
<author>
<firstname>Jesper</firstname>
<surname>Skov</surname>
</author>
</authorgroup>
<address><email>jskov@cygnus.co.uk</email></address>
<copyright><year>1998</year><holder>Jesper Skov</holder></copyright>
<abstract>
<para>This document contains frequently asked questions (and
answers) about &linapus; (&linux; for &amiga; &pup; Systems) as
well as general documentation of the &linapus; port.</para>
</abstract>
</bookinfo>
<toc></toc>
<part><title>User Help</title>
<partintro>
<para> Hello!</para>
<para> Welcome to the user part of &thisdoc;. I hope
you will find what you are looking for.</para>
<para> It's very important that this document,
presumably being the first stop for new &linapus; users, is
good enough to get <emphasis>you</emphasis> and the ones after
you from &ados; to &linapus; with as few problems as
possible. Please send suggestions for improvement to the
maintainer at <ulink
url="mailto:apus@linux-m68k.org">apus@linux-m68k.org</ulink>.
<emphasis>Do not</emphasis> send questions to that address -
there are better places to ask for answers to your
questions. Please read on.</para>
<para>Thanks,</para>
<para>Jesper</para>
</partintro>
<chapter>
<title>Introduction</title>
<para> The &linux; port for APUS (&amiga; &pup; Systems) was
started in 1997 with support from <ulink
url="http://www.phase5.de">&p5;</ulink> who provided 3 developer
boards to Jes Sørensen, Roman Zippel and Jesper Skov.</para>
<para>Initially it seemed that the proprietary information needed
to make the port would make a bad mix with the open source model
of &linux;. Indeed, it postponed the public release of &linapus;
somewhat, but it all worked out in the end. &p5; have approved
all the released information and, sparse commenting aside, all
source code changes are freely available.</para>
<sect1><title>&linux; ports</title>
<para>I refer to the following ports of &linux; in this
document:</para>
<para> <emphasis>&linm68k;</emphasis> The port for the Motorola
&cpum68k; CPU family. This is what you would use for running
&linux; on an &amiga; without &pup;. It is also the port that
&linapus; is based on, since all the drivers are the same.</para>
<para><emphasis>&linppc;</emphasis> The port for the Motorola
&cpuppc; CPU family. The home of this port is at <ulink
url="http://www.linuxppc.org">www.linuxppc.org</ulink>. This
port has multi-machine support, including PMAC, PREP, CHRP and
partially APUS.</para>
<para><emphasis>&linapus;</emphasis> The port targeted at &amiga;s
with &p5;'s &pup; hardware. With time, it will be a proper
part of &linppc;. It may also become a base for the support of
&cpuppc; cards from other &amiga; vendors.</para>
</sect1>
<sect1><title>Document Changes</title>
<para>I will try to keep this document up to date, but if you
find something that is obsolete or wrong, please let me
know. Things marked with <emphasis>FIXME</emphasis> are known
to be incomplete or (maybe) wrong.</para>
<para> New changes in the document are marked with
colors. Recent changes are red, and as the changes age they
fade to blue and then black over a period of 14 days or
so. Sections containing these colored changes will be dated so
they can be easily identified from the table of contents. The
colors work fine (IMO) with the default Netscape colors. If
you use a customized color scheme, you might want to generate
the HTML pages without the colors: use the DocBook
<application>db2html</application> and the file
<filename>faq.sgml</filename> from the docs directory at
&sunsite;.</para>
</sect1>
</chapter>
<chapter><title>Getting The Kernel</title>
<para> Precompiled kernel images and a special version of
&amiboot; (called &boothack;) can be downloaded from
&sunsite;.</para>
<para> Before you download anything, you should read <xref
linkend="working"> and <xref linkend="problems"> to prevent
yourself from getting a nasty surprise. Also, I suggest you
start by downloading only what is needed to get a minimal
system installed (see <xref linkend="installing">) - if this
is working you can then download the applications you want to
run.</para>
<sect1><title>The Kernel Images</title>
<para> The kernel archives at &sunsite; (see <xref
linkend="sunsite">) are named
<filename>vmapus-YYMMDD.lzh</filename> and contain three files:
<filename>vmlinux</filename> (the actual kernel image),
<filename>System.map</filename> (a list of symbols/addresses in
the kernel) and <filename>.config</filename> (describing how the
kernel was configured).</para>
<para>You only need the kernel image to boot &linux;, but the
other files may help track down bugs. Please read <xref
linkend="debug"> for information about how you can use a
kernel dump and the <filename>System.map</filename> file to
help yourself or others locate a bug.</para>
<para>It is not customary to provide precompiled images of a
developer kernel, but I have chosen to do so because not
everybody have the disk space to install two separate systems
(i.e., a &linm68k; system just for compiling &linapus;
kernels). When &linapus; becomes more stable (that is, when
enough drivers are reported working) I will stop providing the
precompiled kernels. People who want the bleeding edge stuff
should then recompile their kernels themselves (see <xref
linkend="recompile">).</para>
<sect2><title>Included Hardware Drivers</title>
<para>The precompiled kernel image includes drivers for the
hardware listed below. The drivers are
<emphasis>exactly</emphasis> the same as in &linm68k; so they
will not work better (or worse, hopefully) and you need to
take the same precautions with some of the drivers (e.g.,
CyberVision) as you would in &linm68k;. Consult the &linm68k; FAQ
(see <xref linkend="links">) if you have problems.</para>
<para>A list of drivers that are known to
<emphasis>work</emphasis> can be found in <xref
linkend="working">.</para>
<informaltable frame="all">
<tgroup cols="2">
<thead>
<row>
<entry>DISPLAY</entry>
<entry>BLOCK</entry>
<entry>CHAR</entry>
<entry>NET</entry>
<entry>SCSI</entry>
</row>
</thead>
<tbody>
<row>
<entry>OCS, ECS, AGA, CyberVision, CyberVision/3D,
PM2 (CyberVision/PPC)
<footnote>
<para> The driver included in the
precompiled kernel is an old beta. If you want
the up-to-date version get the latest sources
from the PM2 webpage (see <xref
linkend="links">). Don't expect the
precompiled version to behave as described on
the webpage!</para>
</footnote>, RetinaZ3, Clgen</entry>
<entry>&amiga; floppy, A1200/A4000 IDE, IDEDoubler,
Buddha</entry>
<entry>&amiga; serial, &amiga; keyboard, &amiga;
mouse, &gvp; IO extender (ser),
MultifaceIII ser, Whippet</entry>
<entry>Ariadne, AriadneII, A2065, Hydra</entry>
<entry>
A3000, A4091+A4000T<footnote id="a4000tscsi">
<para>You have to disable the use of BATs to map
main memory. Add <option>"nobats"</option> to
your kernel options. There are
still some stability problems with this driver
under &linapus;.</para>
</footnote>
, BlizzardPPC<footnote id="blzscsi">
<para>You have to disable the use of BATs to map
main memory. Add <option>"nobats"</option> to
your kernel options.</para>
</footnote>
, A2091, GVP11
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>If you have hardware for which you would like to see an
<emphasis>existing</emphasis> &linm68k; driver included, please
let me know. You should restrict your request to something
you need to get your system installed as the precompiled
kernel is already pretty big. Some drivers will be include
for testing purposes (like sound) and be removed again when
they have been reported as working.</para>
<!-- EMPTY LIST
<para>The following drivers have been requested, but I'm not
able to compile them out of the box:</para>
<itemizedlist>
</itemizedlist>
<para>If you have the above hardware and know C, you can help
yourself and others by trying to get it to compile with
&linapus;, or help get it properly integrated into &linm68k;.</para>
-->
</sect2>
<sect2><title>Included Software Drivers</title>
<para>The kernel also includes these software drivers:</para>
<informaltable frame="all">
<tgroup cols="2">
<thead>
<row>
<entry>FS</entry>
<entry>PARTTBL</entry>
<entry>PROTOCOLS</entry>
<entry>MISC</entry>
</row>
</thead>
<tbody>
<row>
<entry>affs, dos, ext2, iso9660, minix, nfs, proc,
vfat, hfs</entry>
<entry>amiga, msdos, mac</entry>
<entry>ppp, slip</entry>
<entry>ram disk, z2/motherboard swap, loop</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
</sect1>
</chapter>
<chapter id="installing"><title>Installing</title>
<para>In this chapter I will try to help you through the steps of
installing a &linapus; system. This is based on the &rhppc; system -
if you want to install another package distribution or compile
applications yourself, you are pretty much on your own. The
only reason for describing how to install a &rhppc; system and
not &debian; is that &rhppc; seems to be (at the moment) the
primary system used by &linppc;. By the way, &rhppc; is not
coordinated by &rh; but by &linppc; developers.</para>
<para>It might be a good idea to read this entire chapter before
you start downloading anything - so you know what is required
for what you want to do.</para>
<para>If you don't know how to do some of the things mentioned
here (or are unclear about something) you should get an install
help text. You should be able to find several by looking for
links at <ulink
url="http://www.linux-m68k.org">www.linux-m68k.org</ulink>.</para>
<para>If you have corrections, additions or comments to this,
please let me know. Your feedback is important for this chapter
since new users (after <emphasis>you</emphasis> there may be
others coming this way, you know!) will probably try to follow
this - any misinformation or errors no matter how trivial should
be corrected.</para>
<sect1><title>Files Required For Booting</title>
<para>You need to get the files found in <xref
linkend="sd-misc">, <xref linkend="sd-install-rh"> and in <xref
linkend="sd-latest">.</para>
<para> You should get the following files (leave them
in the same directory):</para>
<itemizedlist>
<listitem><para><filename>misc/kernel-options.txt</filename></para>
</listitem>
<listitem><para><filename>misc/ramdisk.image.gz</filename>
<footnote>
<para>The <filename>ramdisk.image.gz</filename> is
primarily used to test that &linapus; actually
boots. If you know it boots, don't bother downloading
it.</para> </footnote></para>
</listitem>
<listitem><para><filename>latest/bhYYMMDD.lha</filename></para>
</listitem>
<listitem><para><filename>latest/vmapus-YYMMDD.lzh</filename></para>
</listitem>
<listitem><para><filename>
install/redhat/apus-rh-ramdiskimageYYMMDD.gz</filename></para>
</listitem>
</itemizedlist>
<para>Unpack the archives (the version of
<application>lha</application> I use under &linux; appends the
suffix <filename>.lzh</filename> and I'm bound to forget
renaming them to <filename>.lha</filename> - so I
don't):</para>
<screen>
lha x bhYYMMDD.lha
lha x vmapus-YYMMDD.lzh </screen>
<para>Leave the ram disk compressed, or it will not be
usable.</para>
</sect1>
<sect1 id="booting"><title>Booting &linapus;</title>
<para> This section describes how to boot the kernel. The basic
command required to boot &linapus; using a ram disk as main
file system is:</para>
<screen>
bootstrap --apus -k vmlinux -r ramdisk.image.gz root=/dev/ram </screen>
<para>The <option>root=/dev/ram</option> option tells the kernel
to read its data from the ram disk, <option>-k</option>
specifies the kernel image to boot, <option>-r</option> the
ram disk file and <option>--apus</option> that the &cpuppc; should
be the CPU starting the kernel.</para>
<para>The above is how you would boot on a <emphasis>simple
system</emphasis>. When issuing the command
<command>bootstrap</command> you may need additional
parameters (at the end) for the kernel to work on your
system - this is just the same as if you were booting a
&linm68k; system. Display selection, display resolution,
SCSI driver options and other things are controlled by such
additional options.</para>
<para> There are two specific &linapus; kernel
options:</para>
<itemizedlist>
<listitem><para><option>60nsram</option></para> <para>Use
this to remove RAM waitstates. It requires 60ns
RAM.</para>
</listitem>
<listitem><para><option>nobats</option></para> <para>Use
this to prevent the use of BATs for mapping of main
memory. Selecting this incurs a small performance
overhead, but some drivers depend on each memory page
being individually mapped (A4000T/A4091 SCSI
drivers).</para>
</listitem>
</itemizedlist>
<para>Other kernel options exist, but are shared with
&linm68k; and other ports so I don't describe them here. One
of the files you should download
(<filename>kernel-options.txt</filename>) describes the
options you can use. The &linm68k; website/FAQ should also
contain some general information about the boot
options.</para>
<para> A ram disk image is used to get started. The
ram disk contains a minimal &linux; system from which you
prepare your disks. When you have done this (described in
sections below), you will normally use
<option>root=/dev/xxx</option> (where xxx is the root
partion) to boot your &linapus; system.</para>
<para><emphasis>Notice that booting the &linapus; kernel might
blank the display for as long as 30 seconds depending on the
&cpuppc; speed.</emphasis></para>
<para>Some people have reported problems with copying the ram
disk (and kernel) to RAM: before booting and must use a disk
partition for the files. Others need to copy the files to
RAM:, especially &blzppc; owners who use SCSI disks.</para>
<para>Additional to options for making your hardware run
smoothly with &linux;, you may need to restrict your memory
configuration for &linapus; to work correctly.</para>
<sect2><title>&linapus; Memory Restrictions</title>
<!-- FIXME
<para>Differences between the MMU capabilities of the
&cpum68k; and &cpuppc; CPUs means that &linapus; may not be
able to use as much of your memory as would &linm68k;. To
make matters worse, the physical location of memory on
&blzppc; adds further restrictions.</para>
-->
<para> &linapus; only supports one block of primary
memory which should be the memory on the &pup; board. It
would be possible to support mutiple blocks, but since
there is such a big performance penalty in using other
system memory than the one on the &pup; board, it doesn't
make sense.</para>
<para> The problem is that &linux; uses memory
much more aggressively than &ados; so all memory will be
used constantly. Because of this it is not possible to
prioritize memory blocks as it can be done under
&ados;. This means that you cannot guarantee that the most
CPU intensive applications actually run in the fastest
memory block in the system. For this reason, &linapus;
only support one block of primary memory -- the
fastest. See <xref linkend="fastswap"> for a way of using
additional memory.</para>
<para> If you have multiple memory blocks, the one
on the &cybppc;/&blzppc; will usually have the highest
priority and be selected by default. Unfortunately, this
is not foolproof and you may have to explicitly define the
block to be used.</para>
<para>You control the memory &linux; can see by using a memory
config file: add <option>-m
<filename>file</filename></option> after the
<option>--apus</option> option. This file should contain 2
lines: on the first the size of your chip memory, on the
second the starting address of the memory and its
size. Here's a single example.</para>
<!-- FIXME
I will add a table of options
to use for different memory sizes and locations in <xref
linkend="sec-rs">.</para>
-->
<screen>
2097152
0x08000000 33030144 </screen>
<para>The format of memory files actually allow more memory
blocks to be specified (since it was created for &linm68k;),
but <emphasis>only one</emphasis> memory block can be used
in &linapus;. If you have more than one block of memory in
your system, you must specify the block located on the
&cybppc; or &blzppc; card.</para>
<para>You should be able to get the required numbers from
showconfig or a similar tool under &ados;.</para>
<para>Notice that the size of the memory is 512kB less than
what you would expect (33030144 is 31.5MB). This is normal
<emphasis>and required</emphasis>. The 512kB block is used
to hold the &cpuppc; exception vector table and other &p5;
stuff.</para>
<sect3><title>ROM Shadowing</title>
<para>If you are using the Shadow hardware on your &p5;
&cybppc; or &blzppc; board to remap the &ados; ROM to RAM,
you should either disable this before booting &linapus; or
make sure the memory size reflects this mapping: the
memory size reported by bootstrap should be 1MB smaller
than the amount of RAM in your system. If it is only 512kB
smaller, you have to use a memfile, specifying the total
amount of RAM less the 1MB.</para>
<para>The newer kernels (980725+) will detect the ROM
shadowing (based on the memory size) and will avoid that
chunk of memory. This means 512kB of your memory will
remain unused in &linapus;. <emphasis>If you do not
subtract the 512kB when specifying the size in a memfile,
the kernel will not boot!</emphasis></para>
</sect3>
<!-- FIXME
<sect3><title>Memory Alignment</title>
<para>Currently the memory in &linapus; has to be mapped
using BATs. This means that the physical address of the
memory block must have the same alignment as its
size.</para>
<para>It should be possible to map parts of the memory space
with segment registers but this is not working at the
moment. This restriction will hopefully go away in the
future.</para>
</sect3>
-->
<sect3 id="fastswap"><title>Memory-to-Memory
Swapping</title>
<para> Even though only one block of memory can
be used for primary memory in &linapus; you can use
other memory resources as a fast swapping device. Using
slower memory for swapping makes sense; your
applications are always running in the fast primary
memory on the &pup; board, but the slower memory is
still providing a much faster page swapping service than
the harddisk would.</para>
<para> You specify a block of memory for
swapping by adding a line to the memory file (or by
relying on the default &ados; priority ordering of the
memory blocks). On my box, I have 32MB on the &cybppc;
and 8MB on the motherboard of my A4000. The default
&ados; ordering matches this memory file:</para>
<screen>
2097152
0x08000000 33030144
0x07800000 8388608 </screen>
<para> Again, the default &ados; priority
ordering may do the correct thing for you. If not, you
have to use a memory file.</para>
<para> After booting, you need to tell &linux;
to use the new swapping device. First you must add a new
device node:</para>
<screen>
mknod /dev/fastram b 37 4 </screen>
<para> Each time you boot you have to initialize
the memory area (it doesn't keep its state over reboot
as your swap partition does), and enable it with a
higher priority than the swap partition (put the lines
in <filename>/etc/rc.d/sysinit</filename> or
similar). </para>
<screen>
mkswap /dev/fastram
swapon -p1 /dev/fastram</screen>
<para> In the above only a single memory chunk
is used for swapping. The z2ram device can only handle
one chunk at the moment. However, it can select other
than the second chunk of the memory list; minor numbers
4, 5, 6, and 7 select memory chunks 2, 3, 4, and 5
respectively, chunk 1 being used as primary memory.</para>
</sect3>
<!-- FIXME
<sect3 id="sec-rs"><title>Memory Configuration Examples</title>
<para> FIXME </para>
</sect3>
-->
</sect2>
</sect1>
<sect1><title>The First Step</title>
<para> Before you go any further and start downloading
packages, you should make sure that you can actually boot
&linapus;.</para>
<para> Get the required files for booting and follow
the boot instructions above.</para>
<para> If all goes well &linapus; should boot,
displaying a picture of an (alcoholic :) penguin (called Tux)
in the upper left corner of the screen. Text should be output,
showing the progress of the boot, eventually leaving you with
a # prompt and a blinking cursor (unless you boot with
debug=<whatever> in which case you will not see the
text, only Tux and the prompt).</para>
<para> Your disk partitions should be recognized,
notifying you of this fact with some output similar to:</para>
<screen>
Partition check:
hda: hda1
hdb: hdb1 hdb2 hdb3 hdb4 </screen>
<para> This is a good sign as it means the disk driver
is probably working. Depending on your hardware configuration
you might not see this. Either because there exists no driver
for the disk controller, or because the driver has not been
included in the prebuilt kernel you booted. In both cases,
report your finding to the &linapus; kernel mailing list for
advice.</para>
<para> The ram disk contains a few tools that allow
you to mount disks to see if they work as expected. This ram
disk was used in an older installation scheme, but unless you
really know what you do, you should use the &rh;
installer.</para>
<para> If you got this far, it should be safe for you
to start downloading packages for a proper installation of
your &linapus; system. Good luck!</para>
</sect1>
<sect1 id="preppart"><title>Preparing Partitions</title>
<para><emphasis>Text by Thomas Lohmann</emphasis></para>
<para>The partitions for installing &linapus; should be created
using &hdtbox; which is included in
&ados; since version 2.x. You need at least two partitions,
one for SWAP (as big as your memory is) and one for ROOT. You
have to set the advanced options using
&hdtbox; to ON and set the
filesystem type to "CUSTOM FILE SYSTEM", the identifier has to
be set as follows:</para>
<itemizedlist>
<listitem><para> 0x4c4e5800 (LNX/0) For all major &linux;
partitions.</para>
</listitem>
<listitem><para> 0x53575000 (SWP/0) For the swap
partition.</para>
</listitem>
</itemizedlist>
<para>You can also set "Reserved Blocks at" to 0 for both
beginning and end, but this should not be necessary.</para>
</sect1>
<sect1><title>Installing a &rh; System</title>
<para>You can get precompiled &rh; &rpm; packages from
www.linuxppc.org (see <xref linkend="links">) or its
mirrors. You can also buy the CD-ROM (details at the WEB
site). <emphasis>&rhppc; does not explicitly support
&linapus;. None of the &linapus; developers are affiliated
with the &rhppc; developers. This help is offered "AS IS" --
without any guarantees of your success.</emphasis></para>
<sect2><title>&rhppc; Installation</title>
<para><emphasis>Text by Ken Tyler</emphasis></para>
<sect3><title>Overview</title>
<para>The &rhinstaller; simplifies the process of
partitioning, formatting installing and configuring the
&linux; &rhppc; distribution.</para>
<para>No previously installed &linux; is required, the
installation is started from &ados; by booting a kernel
with the &linapus; ram disk image as the root
filesystem.</para>
<para> The &rhinstaller; has been used to install
from a hard disk partition to other partitions on the same
drive. Christophe Decanini reports that CDROM, FTP and
NFS work.</para>
<para>Note: See <xref linkend="borken"> for a list of
applications that are known to fail.</para>
</sect3>
<sect3><title>Requirements</title>
<itemizedlist>
<listitem><para> A kernel.</para></listitem>
<listitem><para> The latest &linapus; &rhinstaller; ram
disk image (usually named <filename>
apus-rh-ramdiskimageYYMMDD.gz</filename> in
<xref linkend="sd-install-rh">).</para>
</listitem>
<listitem><para> &rpm;s, base files and
<filename>README.installer</filename>. Available on
the &linux; &rhppc; CD-ROM or from <ulink
url="ftp://ftp.linuxppc.org">ftp.linuxppc.org</ulink>
and mirrors.</para>
<para> The base files required are
<filename>comps.pmac</filename>,
<filename>hdlist</filename>,
<filename>skeleton.cgz</filename> and
<filename>uglist</filename>.</para>
</listitem>
<listitem><para> A few moments spent reading
this docment, especially the Problems at the end of
this section.</para>
</listitem>
</itemizedlist>
</sect3>
<sect3><title>What is an &rpm;?</title>
<para> &rpm; is the acronym for &rh; Package
Manager. This is a standalone program that installs
software on to a &linux; system. Files intended for use by
&rpm; have the extension <filename>.rpm</filename>. The
&rhinstaller has a library version of the RedHat Package
Manager in the install ramdisk.image.</para>
</sect3>
<sect3><title>Hard Disks</title>
<para>The &rhinstaller; can partition and format hard disks,
but depending on which install method you use you might
need to partition your hard disk first with
&hdtbox;. On a single drive
system, an AFFS &ados; partition is needed to hold the &rpm;s
in addition to the required &linux; and swap partitions. On a
system with two or more drives, or when using the other
install methods the installer can do the partitioning and
formatting of the drive(s).</para>
<para>On the AFFS drive or partition a directory <filename
class=directory>RedHat</filename> with subdirectories
<filename class=directory>RPMS</filename> and <filename
class=directory>base</filename> should be created. The
<filename class=directory>base</filename> directory should
hold the <filename>comps.pmac</filename>,
<filename>hdlist</filename>,
<filename>skeleton.cgz</filename> and
<filename>uglist</filename> files. The <filename
class=directory>RPMS</filename> directory is the place for
the collected &rpm;s.</para>
<para> The suggested &rh; minimum system is about
25MB of &rpm;s which needs about 70MB of &linux; disk
space.</para>
</sect3>
<sect3><title>Components "comps" file and <filename
class=directory>RPMS</filename></title>
<para> Read the
<filename>README.installer</filename> for info on the
<filename>comps.pmac</filename> file format. Basically
there are two types of line; separator lines and &rpm;
prefix lines. Separator lines start with a digit or the
word 'end' and divide the &rpm;s into groups, &rpm; prefix
lines are partial &rpm; names. An indented &rpm; prefix
line implies that the &rpm; specified by the preceding
non-indented line is required. If the
<filename>comps.pmac</filename> file has entries for
&rpm;s that don't exist in the <filename class=directory>
RPMS</filename> directory the installer complains about
them but will work, but to avoid saying OK to many
warnings edit the <filename>comps.pmac</filename> file to
include only the &rpm;s you have.</para>
<para>The long filenames of some &rpm;s are chopped at the
&amiga; 32 character limit but this is not a problem since
&rpm; will scan the packages for their full name.</para>
</sect3>
<sect3><title>Installing</title>
<para>Copy the
<filename>apus-rh-ramdiskimageYYMMDD.gz</filename> to RAM:
and boot specifying:</para>
<screen>
-r ram:apus-rh-ramdiskimageYYMMDD.gz root=/dev/ram </screen>
<para>in addition to the usual <option>--apus</option>,
<option>-k</option>, and <option>-m</option> options as
required.</para>
<para>I use (all on one line) :</para>
<screen>
boothack --apus -v -d -m memfile -k ram:vmlinux -r ram:apus-rh-ramdiskimageYYMMDD.gz root=/dev/ram </screen>
<para>If all goes well a window asking if you have a color
monitor will appear.</para>
<para>(Respond to the windows with <keycap>CR</keycap> to
enter, <keycap>SPACE</keycap> to toggle on/off and
<keycap>TAB</keycap> to move between buttons, cursor
arrows to move up and down lists.)</para>
<para>Now comes a succession of windows guiding you through
the installation. Reply to these to suit your system.
Choose install at the install/upgrade window. Eventually
you should get to the window asking what packages to
install. Select what you require or the "everything"
option at end of the list.</para>
<para>After the Package install finishes there may be much
disk activity as the &rpm; database is created.</para>
<para>A few more windows, networking timezone and root
password.</para>
<para>Finally an "OK to reboot" screen should appear but
wait till the disk activity stops before
rebooting.</para>
<para> During the the install,
<keycap>CTRL</keycap>-<keycap>Z</keycap> brings a shell
up, entering <command>exit</command> returns you to the
installer. <keycap>ALT</keycap>-<keycap>F1</keycap> to
<keycap>ALT</keycap>-<keycap>F4</keycap> select installer,
a shell, installer log and kernel log virtual
consoles. To get <keycap>F11</keycap> to <keycap>F20</keycap>
use <keycap>SHFT</keycap>-<keycap>F1</keycap> etc.</para>
</sect3>
<sect3><title>Required RPMS</title>
<para> To create a list of the suggested required
&rpm;s for a minimum system, take the &rpm; prefixes in
the '1 *beforeskel*' and the '1 Base' sections of the
<filename>comps.pmac</filename> file and expand them into
the full &rpm; name as contained in the <filename
class=directory>RPMS</filename> directory.</para>
</sect3>
<sect3><title>Problems</title>
<para> Flashing console problem. The current CD
(as at 27-Oct-98) writes an
<filename>/etc/inittab</filename> that attempts to start X
at the default run level of 3 rather than run level 5. As
kernels from 2.1.120 to the 981026 release have problems
with X on some hardware, the result is alternating flashes
of login screens and blank X screens. To avoid this,
either get a 981031 or newer kernel, or fix the
installation: when the installation finishes don't respond
to the "Congratulations" window but hit
<keycap>ALT</keycap>-<keycap>F2</keycap> and edit
<filename>/mnt/etc/inittab</filename>. All that needs to
be done to <filename>/mnt/etc/inittab</filename> is to
swap the comment '#' char on the last two lines of the
file. To run any of the newly installed editors you need
to specify a full path, the installed system is on /mnt.
Now hit <keycap>ALT</keycap>-<keycap>F1</keycap> and
confim the "Congratulations" window. Thanks to Kolbjørn
Barmen for suggesting this approach. If you have already
installed the the X components and are seeing the flashing
console, you need to login and edit
<filename>/etc/inittab</filename> and make the above
change. Can be difficult to login through the flashing but
it can be done. Look at the top left of the screen to see
the password characters that <emphasis>don't</emphasis>
get to the password prompt (retype these).</para>
<para> The first version of the installer was
incorrectly named
<filename>apus-rh-ramdisk.image130698.gz</filename>,
should have been called
<filename>apus-rh-ramdisk.image980613.gz</filename>.</para>
<para>NOTE: <filename>apus-rh-ramdisk.image981003</filename>
requires the <filename>comps</filename> file to be named
<filename>comps.pmac</filename>, for earlier versions of
the installer, rename <filename>comps.pmac</filename> to
<filename>comps</filename>.</para>
<para> If you have a 4.2 CD February 98 use
<filename>apus-rh-ramdisk.image130698.gz</filename>, if
you have the 5.0 CD or try the other install methods use
<filename>apus-rh-ramdisk.image981003</filename>. The
130698 installer has problems with the 'noarch' files in
the 5.0 distribution.</para>
<para> Three of the &rpm;s on the 4.2 CD have
errors when installing.
<filename>dailyscript-3.1-2.ppc.rpm</filename> writes a
message over the progress screen,
<filename>latex2html-96.1.revh-4.ppc.rpm</filename> and
<filename>xmahjongg-2.0-1A.ppc.rpm</filename> fail with
install script failed.</para>
<para> I have yet to do a full install from the
5.0 CD. Installing the suggested base was free of
errors.</para>
<para> Some users have a reported a 'missing kernel error'
when attempting to install from downloaded &rpm;s. The
installer tries to put a kernel into the <filename
class=directory>/boot</filename> directory. There is no
reason to do this as the kernels available on linuxppc.org
are not &linapus; kernels. To avoid this edit the
<filename>comps.pmac</filename> file and remove the two
(4.2) or three (5.0) lines
<filename>kernel-prep</filename>,
<filename>kernel-pmac</filename>,
<filename>kernel-pmac-modules</filename>.</para>
<para>Comments, feedback about success or failure most
welcome, I read the &linapus; list daily.</para>
</sect3>
</sect2>
<sect2><title>&rhrc; Installation</title>
<para> &rh; has released a CD set named Linux Rough Cuts,
containing (unsupported) &rh; ports for (among other CPUs)
&cpuppc; and &cpum68k;. The &cpuppc; installation is
intended for MkLinux, but it's possible to use it for
&linapus;.</para>
<para> Basically you should follow Ken's instructions
above. There are a few differences, primarily because the
&rhrc; CD does not contain all the required install
files. But follow the below instructions, and you should
come out of it OK anyway.</para>
<para> Get the file
<filename>rh-roughcuts-981108.tgz</filename> from <xref
linkend="sd-install-rh">. It contains what you need to get
started.</para>
<para> The layout of the &rhrc; CD is wrong (for the &linapus;
installer), and is missing files (probably because it's
intended to be used from MacOS). You have to create a
correct layout. You can do this in at least two ways; 1)
install via FTP and create the correct layout on another
Linux box using soft links (I did this) 2) install from
harddisk, having copied the CD contents to a harddisk and
added the extra bits.</para>
<para> Below the tree structure of the directory I created on
Concubine for installation on Cyber (-> is a soft link
to the file or directory on the &rhrc; CD). During
installation I set the FTP directory to the path
containing <filename>RedHat</filename> you see as the top
node below.</para>
<screen>
`-- RedHat
|-- RPMS -> /mnt/cdrom/RedHat/RPMS
|-- TRANS.TBL -> /mnt/cdrom/RedHat/TRANS.TBL
|-- base
| |-- RedHat -> /mnt/cdrom/RedHat/
| |-- TRANS.TBL -> /mnt/cdrom/RedHat/base/TRANS.TBL
| |-- comps.pmac
| |-- hdlist -> /mnt/cdrom/RedHat/base/hdlist
| |-- skeleton.cgz
| `-- uglist
|-- ppc -> /mnt/cdrom/RedHat/ppc
`-- rpmcontents.gz -> /mnt/cdrom/RedHat/rpmcontents.gz </screen>
<para> The structure is found in the
<filename>rh-roughcuts-981108.tgz</filename> archive; you
might want to use it as a base. If you create it yourself,
there are three files in there that you need to
include:</para>
<itemizedlist>
<listitem><para><filename>comps.pmac</filename> The
<filename>comps</filename> file from the base
directory of the disk. The two &rpm; packages
<emphasis>MAKEDEV</emphasis> and
<emphasis>dev</emphasis> have been moved down as the
last to be installed due to some problem I couldn't
track down.</para>
</listitem>
<listitem><para><filename>skeleton.cgz</filename> The
skelton file from the &rhppc; installation containing
a few extra files.</para>
</listitem>
<listitem><para><filename>uglist</filename> The skelton
file from the &rhppc; installation.</para>
</listitem>
</itemizedlist>
<para> When you have this set up, installing is done exactly
as with the &rhppc; CD. <note><para>The text printed out
before the login prompt is from the &linppc; skeleton, so
it is somewhat misleading...</para>
</note></para>
</sect2>
</sect1>
<sect1><title>Installing a &debian; System</title>
<para>You can get precompiled &debppc; &deb; packages from
www.debian.org (see <xref linkend="links">) or its
mirrors. Currently no &cpuppc; version of the &debian;
CD distribution exists.</para>
<sect2><title>Installation</title>
<para><emphasis>Text by Michel Dänzer</emphasis></para>
<para>First of all, be aware that installing &debian; is
quite a bit harder at the moment than installing
&rhppc;. I mention this so nobody downloads lots of stuff
and then has to give up frustrated. There is no CD-ROM
release until now, the guys at &debppc; want to wait until
it's virtually equal to the i386 &deb;. However, if
you've got the time and will to experiment a little, give
it a go! You won't be deceived :-)</para>
<para><emphasis>Please read all the instructions carefully
before you start.</emphasis></para>
<sect3><title>Preparing the filesystems</title>
<para>You need to have an empty ext2 partition, which will
be the root partition. You will probably need a swap
partition and maybe others as well. It's up to you how
you arrange things. You might want to read <xref
linkend="preppart"> first.</para>
</sect3>
<sect3><title>Installing the base filesystem</title>
<para>Get a base tarball. I have uploaded one to sunsite,
it should be in <xref linkend="sd-install-deb">. Get the
<filename>rd-deb-install.gz</filename> ramdisk
there. You might want to download or at least look at
the other files there as well.</para>
<para>Unpack the base tarball. I'll quickly describe how
to do this with the
<filename>rd-deb-install.gz</filename>.
</para>
<para>Boot the ramdisk. Init will ask you to enter the
runlevel, type 'S' and press enter there. Now you'll see
a rather ugly prompt, however, it's bash, so you have
all the commodities like command history etc. Format the
root partition (I call it /dev/sda2 here because that's
my root partition at home; replace it with
<emphasis>your</emphasis> root partition):
</para>
<screen>
mke2fs /dev/sda2 </screen>
<para>Mount the soon-to-be root partition at /mnt/root: </para>
<screen>
mount -t ext2 /dev/sda2 /mnt/root </screen>
<para>Mount the Amiga partition containing the base
tarball at /mnt/amiga (Again, replace /dev/sda4 with
your partition ;):
</para>
<screen>
mount -t affs /dev/sda4 /mnt/amiga </screen>
<para>CD to the base tarball's directory and unpack it with:
</para>
<screen>
tar xvzpf base2_1.2.0.11.4_1998-10-15.tgz -C /mnt/root </screen>
<para>The <option>p</option> switch is vital, it sets all
permissions correctly.</para>
<para>Remove the <filename>unconfigured.sh</filename>
script which would prevent the thing from booting (Note:
if you're unlucky and have the first version of
<filename> rd-deb-install.gz</filename>, you will have
to use <filename>/mnt/root/bin/rm</filename>):
</para>
<screen>
rm /mnt/root/sbin/unconfigured.sh </screen>
<para>You need to create
<filename>/mnt/root/etc/fstab</filename>, or else init
won't be able to mount the filesystems at boot time. You
can use <filename>joe</filename> to do that:
</para>
<screen>
joe /mnt/root/etc/fstab </screen>
<para>Press CTRL-K and then H for help. CTRL-K X to save the
file.</para>
<para><emphasis>FIXME: Unfortunately, there is no template
fstab in this base tarball anymore.</emphasis> If you
don't know how to set it up, refer to other FAQs (I
would be glad if someone could add an example here -
or maybe I'll do it sometime :).</para>
<para>Now you're set for a first boot into your shiny new
&debian; root partition! Remember to unmount all
filesystems before rebooting.</para>
<screen>
umount /mnt/root
umount /mnt/amiga </screen>
</sect3>
<sect3><title>The first boot</title>
<para>It should boot right through to the login
screen. You must login as root.</para>
<para>Now you can start installing additional
packages. All the needed stuff like pppd, ftp, etc. is
there, so the main problem remaining is probably setting
up pppd. Try <application>pppconfig</application>, a
tool for that purpose with a User Interface. If that
doesn't work, bad luck, check out the PPP-Howto at
<ulink
url="http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html">
http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html</ulink>
</para>
<para>Once this works, <application>dselect</application>
can download the packages you want automatically via
FTP. Just choose FTP as the installation method. The
main server is ftp.debian.org, but you'll probably
prefer a mirror close to you. Read
<ulink url="http://www.debian.org/misc/README.mirrors">
http://www.debian.org/misc/README.mirrors </ulink> for
a list. There's also a mirror at &sunsite; in <filename
class="directory"> /mirrors/ftp.debian.org</filename>.
The distribution directories are <filename
class="directory">
debian/dists/unstable/main</filename> and
optionally <filename class="directory">
debian/dists/unstable/contrib</filename>
and <filename class="directory">
debian/dists/unstable/non-free</filename>. The
location of the non-us files varies from mirror to
mirror.</para>
<para>You should update the libc and libstdc++ packages
ASAP. This may break some packages, just update them to
the latest version. E.g. you'll probably have to update
the dpkg and tar packages.</para>
<para>Congratulations, you should be using &debppc;! ;-)</para>
</sect3>
<sect3><title>X</title>
<para>Unfortunately, you can't get X to work with the
packages from the official FTP archive. Try the packages
Sven built for you in <xref linkend="sd-deb">. You need
at least the xbase, xbase-clients, xfonts-base, xlib6g,
xserver-common, xserver-fbdev and xterm
packages. Install them directly with dpkg:</para>
<screen>
dpkg -i <path to the files>x*.deb </screen>
<para>You also need a window manager;
<filename>twm</filename> in <xref linkend="sd-deb"> is a
very simple one to start, there are lots in the official
archive.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="borken"><title>Software With Known Problems</title>
<para>Some &rhppc; packages don't mix well with
&linapus;. Please help me keep this list up to date so people
don't have to download useless packages.</para>
<itemizedlist>
<listitem><para> The <filename>kbd*</filename> packages messes
up the keyboard layout. Do not install them. Supposedly
there are &amiga; keyboard patches for the recent kdb
packages. I have not tried it myself though. </para>
</listitem>
<listitem><para> <application>Emacs-nox</application> core
dumps. This is a generic problem. The
<application>emacs</application> compiled with X libs
works fine.</para>
</listitem>
<listitem><para> <application>Gpm</application> requires a
small patch to be working. This is available from <xref
linkend="sd-misc"> (provided by Holger Jakob). The
patch is not needed for <application>Gpm</application>
version 1.16 and above. You may also have to add
<literal>MOUSETYPE='BUSMOUSE'</literal> to
<filename>/etc/sysconfig/mouse</filename>.</para>
</listitem>
</itemizedlist>
</sect1>
</chapter>
<chapter id="applications"><title>Applications</title>
<para> This chapter contains a few random notes on
applications for &linapus;. </para>
<para> You can get precompiled software for a complete
system in both &rh; and &debian; packages (see <xref
linkend="links">). The thing to remember when looking for
applications is that &linapus; is binary compatible with
&linppc; so you should have no problems finding
software.</para>
<para>Some commercial applications are also available for
&linux;, but only in binary form. You would have to persuade
the company to start shipping &cpuppc; compiled binaries in
that case. I can imagine some of the other &linppc; sites
would be coordinating such efforts, or at least it seems like
a good idea to do.</para>
<sect1><title>X</title>
<para>In order to run &x; you need to get a version of the &x;
server compiled for &cpuppc; with support for the &amiga;
hardware. Luckily, such a server is provided by Geert
Uytterhoeven at
<ulink
url="http://www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz">
www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz
</ulink> (You might find a newer version than this).
</para>
<para>date990322 You should also get
<application>fbset</application> from Geert's site:
<ulink
url="http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz">
www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz</ulink>
(again, there may be a newer version). This file may
also be useful: <ulink
url="http://www.cs.kuleuven.ac.be/~geert/bin/fb.modes.gz">
www.cs.kuleuven.ac.be/~geert/bin/fb.modes.gz</ulink>
</para>
<para>Unzip the &x; server and copy it to
<filename>/usr/X11R6.3/bin/X</filename>.</para>
<para>Now get the example <filename>XF86Config</filename> file
from <xref linkend="sd-misc"> and copy it to
<filename>/etc/XF86Config</filename>.</para>
<para>Next, you have to create some &amiga; specific devices
which are not included in the &rhppc; packages:</para>
<screen>
cd /dev
mknod fb0current c 29 0
mknod amigamouse c 10 4
ln -s fb0current fb0
ln -s amigamouse mouse </screen>
<para>Now you should be ready to start up &x; by issuing the
command "<application>startx</application>".</para>
<sect2><title>&x; and graphics cards</title>
<para>There are a few more details to sort out if you want
to run &x; on a graphics card. This text is specific to
CyberVision and CyberVision/3D -- but it might help you
get &x; running on other cards. Please let me know of your
success if you try that.</para>
<para>Note: You have to use the same pixel clock under
&linapus; as you use under &ados;</para>
<para> <emphasis>Text by Jeffrey W. Davis</emphasis></para>
<para>I just wanted to inform everyone that &linapus; and the
CV64 is working. I do not have the CV64/3D, but apparently
it is also working. From what I have seen for the CV64/3D
you need to substitute <option>"virge"</option> for any
instance where I mention <option>"cyber"</option>.</para>
<para>(The frame buffer label <option>"cyber"</option>
selects the CyberVision64 driver and
<option>"virge"</option> the Cybervision64/3D
driver.)</para>
<para> I use a simple boot script as follows:</para>
<screen>
copy bootstrap ram:boothack
boothack --apus -v -k ram:vmlinux root=/dev/hda3 video=cyber:1024x768-8 </screen>
<para>Apparently, only resolutions understood by &linux; work
at present. Therefore, you should choose
<option>640x480</option>, <option>800x600</option>, or
<option>1024x768</option> in the above statement. I believe
all of them have been reported to work. I'm sure that there
are others, but I haven't done much experimentation at this
point.</para>
<para>Make sure that before you boot &linapus;, that your
CyberGfx video mode matches what you have selected to boot
&linapus;. I believe the two key factors in the command
line are the <option>-v</option> and <option>video=</option>
options. You should be able to modify the rest to suit your
configuration.</para>
<para>Once you have successfully booted &linux; you will see
the penguin drawing and probably a much higher resolution
that what you have seen before.</para>
<para>To run &x; you will need to specify the resolution in
the <filename>/etc/XF86Config</filename> file. There is
an example in the same directory as where you found Geert
Uytterhoeven's &x; server. To figure out what parameters
you need, use "<command>fbset -x</command>"
<footnote>
<para>You will also find
<application>fbset</application> in the, by now,
famous directory with Geert Uytterhoeven's &x;
server.</para>
</footnote>
which will show you what you are currently using. If you
are running in an interlaced mode, the
<application>fbset</application> program will show you
values that your monitor will not actually support.
BUT... these values will work properly. Simply LIE about
the scanrate in your monitor definition in the
<filename>XF86Config</filename> file. It will work. Use
the values returned from <application>fbset</application>
and you should be able to start X with no problem.
<footnote>
<para>I'd like to see this paragraph rewritten - I
wouldn't want someone accidently blowing up their
monitor. Users, do be careful! -Jesper</para>
</footnote></para>
<para>If I use the same resolution for everything, with only
one resolution specified for X everything works great. Good
luck! Really... it works!</para>
</sect2>
<sect2><title>&x; on PAL-lace or NTSC-lace screens</title>
<para> <emphasis>Text by Marco De Vitis</emphasis></para>
<para> You have to start &linux; in the screenmode
you want to use, through the
<option>"video=amifb:pal-lace"</option> or
<option>"video=amifb:ntsc-lace"</option> options on the
bootstrap command line; you can then start &x; making it
use the current screenmode. If you already followed the
instruction about running &x; above, the only thing you
need to do is edit your
<filename>/etc/XF86Config</filename> file so that the last
section "Screen" only contains one "Display" subsection
about the "default" mode:</para>
<screen>
SubSection "Display"
Modes "default"
EndSubsection </screen>
<para> You can alternatively use Geert Uytterhoeven's
<filename>XF86Config.pmac</filename> file found at
<ulink
url="http://www.cs.kuleuven.ac.be/~geert/bin/XF86Config.pmac.gz">
www.cs.kuleuven.ac.be/~geert/bin/XF86Config.pmac.gz
</ulink>
decompressing it and copying it in your system as
<filename>/etc/XF86Config</filename>, as it is already set
up like that. But you'll probably need to edit it anyway
to make it work, changing the line:</para>
<screen>
Device "/dev/adbmouse" </screen>
<para>to:</para>
<screen>
Device "/dev/mouse" </screen>
<para> Please note that &x; won't be much usable
in 640x400 or even 640x512, and the current (at the time
of writing) version of <application>XFree86</application>
doesn't support the "Virtual" option for the "default"
mode, but it will do it in the upcoming version 3.3.3,
allowing you to have a virtual screen bigger than your
actual screensize.</para>
</sect2>
<sect2><title>Exotic &x; problems :)</title>
<sect3><title> VGA mode sync problem</title>
<para> <emphasis>Text by Matthias Goerdeler</emphasis></para>
<para> After installing &x; for use with AGA
vga-mode (just use the <filename>XF86Config</filename>
found in <xref linkend="sd-misc">) as described earlier
I could start &x;, but the monitor just didn't sync. So
if your problem is that X does not start, this will
probably not help you.</para>
<para> I got my monitor to sync after changing
the line <emphasis>A</emphasis> to line
<emphasis>B</emphasis> in the monitor section of
<filename>XF86Config</filename>:</para>
<screen>
[A] HTimings 640 760 804 916
[B] HTimings 640 750 804 916 </screen>
<para> It should be pointed out that I do not
know how to calculate the correct timing values, it was
just 'try and error'. And it is not even sure that this
will help you if you run into the same problem as I
did. But you could give it a try and report your
findings to the linux-apus mailing list.</para>
</sect3>
</sect2>
</sect1>
<sect1><title>Compiling Applications</title>
<para>You can also compile many applications yourself as the
source code is often freely available. This is likely to be
necessary if you want to use an application that is not
maintained by either the &rhppc; or &debian; teams, as the
application author(s) would probably only supply a precompiled
version of the application for the ix86 architecture.</para>
<para> Some applications need Linux header files to
build. These are normally found in <filename
class=directory>/usr/include</filename> in the directories
<filename class=directory>asm</filename> and <filename
class=directory>linux</filename>. When using &linapus; the
header files installed by e.g. &rhppc; should be OK for most
applications. However, if you decide to replace the default
header files with &linapus; specific header files you must
also include the directory <filename
class=directory>/usr/include/asm-m68k</filename> which must be
either a copy of the <filename
class=directory>linux/include/asm-m68k</filename> directory or
a link to it.</para>
<!--
<para>When you recompile applications (or shared libs) you
should use egcs-1.1 and the egcs patches found in <xref
linkend="sd-misc">. Without the patches, the application might
get spurious SIGABRTs while running.</para>
-->
</sect1>
</chapter>
<chapter id="working"><title>Working Hardware And Drivers</title>
<para>When I get reports of hardware configurations that are known
to work with &linapus; I put them in this section. You can match
these against your own configuration to get an idea of whether
&linapus; will work on your box.</para>
<para> Note that things listed here are not
necessarily included in the precompiled kernels.</para>
<para>In comments are listed the people who reported the
information - if you have information about a driver currently
not on this list (or conflicting information) please let me
know.</para>
<para>&cybppc; and &blzppc; boards:</para>
<itemizedlist>
<listitem><para> A4000/o3o with &cybppc; &cpu604;@150MHz
(Jesper Skov).</para>
</listitem>
<listitem><para> A4000/o4o with &cybppc; &cpu604;@200MHz
(Jeffrey W. Davis).</para>
</listitem>
<listitem><para> A4000/??? with &cybppc; &cpu604;@233MHz
(Jens K. Jensen).</para>
</listitem>
<listitem><para> A1200 with &blzppc; &cpu603;@160MHz
(Jouko Pynnonen, Sven Luther).</para>
</listitem>
<listitem><para> A1200 with &blzppc;
&cpu603;@200/210MHz (Michel Dänzer).</para>
</listitem>
<listitem><para> A1200 with &blzppc;
&cpu603;@240MHz (Alan Buxey).</para>
</listitem>
<listitem><para> A3000T with &cybppc; &cpu604;@233MHz
(Francisco Sepulveda).</para>
</listitem>
</itemizedlist>
<para> Device Drivers:</para>
<itemizedlist>
<listitem><para> DISPLAY : AGA display. (Jesper Skov)</para>
</listitem>
<listitem><para> DISPLAY : CyberVision(/3D). (Sven Ottemann/Jimmy)</para>
</listitem>
<listitem><para> DISPLAY : Picasso II Clgen. (Francisco Sepulveda)</para>
</listitem>
<listitem><para> DISPLAY : PM2 (Ilario Nardinocchi)
<footnote>
<para> The driver included in the precompiled
kernel is an old beta. If you want the up-to-date
version get the latest sources from the PM webpage
(see <xref linkend="links">). Don't expect the
precompiled version to behave as described on the
webpage!</para>
</footnote>
</para>
</listitem>
<listitem><para> FLOPPY : &amiga; floppy disk controller. (Sven
Ottemann)</para>
</listitem>
<listitem><para> IDE : A4000 IDE controller. (Jesper Skov)</para>
</listitem>
<listitem><para> I/O : &amiga; serial. (Jesper Skov).</para>
</listitem>
<listitem><para> I/O : &amiga; printer. (Bartek Kozakiewicz)</para>
</listitem>
<listitem><para> NET : A2065. (Jesper Skov)</para>
</listitem>
<listitem><para> NET : Ariadne. (Thomas Lohmann)</para>
</listitem>
<listitem><para> NET : Ariadne II.
<footnote id="ariadne2">
<para>There's a performance problem with the driver. It
runs at 10% of the speed compared with the &ados;
driver.</para>
</footnote>
(Martin Koenig)</para>
</listitem>
<listitem><para> NET : Hydra. (Francisco Sepulveda)</para>
</listitem>
<listitem><para> NET : SurfSquirrel. (Carlos Mayo)</para>
</listitem>
<listitem><para> SCSI : A3000/T SCSI controller.
(Thomas Haller/Arno Griffioen)</para>
</listitem>
<listitem><para> SCSI : GVP 11 SCSI controller. (Alex Kazik)</para>
</listitem>
<listitem><para> SCSI : GVP A2000-HC+8 Series II. (Thomas
Lohmann)</para>
</listitem>
<listitem><para> SCSI : Oktagon 2008 SCSI. (Carsten Pluntke)</para>
</listitem>
<listitem><para> SCSI : A4091/4000T SCSI controller.
<footnote id="a4000tscsi2">
<para>You have to disable the use of BATs to map
main memory. Add <option>"nobats"</option> to
your kernel options. There are
still some stability problems with this driver
under &linapus;.</para>
</footnote>
(Ken Tyler)</para>
</listitem>
<listitem><para> SCSI : Blizzard/PPC SCSI
controller.<footnote id="blzscsi2">
<para>You have to disable the use of BATs to map main
memory. Add <option>"nobats"</option> to your kernel
options.</para>
</footnote>
(Sven Luther)</para>
</listitem>
<listitem><para> SOUND :
&amiga; DMA sound. (Carsten Plunkte)</para>
</listitem>
</itemizedlist>
<para>Software Drivers:</para>
<itemizedlist>
<listitem><para> FS : affs (Jesper Skov).</para>
</listitem>
<listitem><para> FS : dos (Sven Ottemann).</para>
</listitem>
<listitem><para> FS : ext2 (Jesper Skov).</para>
</listitem>
<listitem><para> FS : hfs (Bartek Kozakiewicz).</para>
</listitem>
<listitem><para> FS : iso9660 (Bartek Kozakiewicz).</para>
</listitem>
<listitem><para> FS : joliet (Bartek Kozakiewicz).</para>
</listitem>
<listitem><para> FS : minix (Jesper Skov).</para>
</listitem>
<listitem><para> FS : proc (Jesper Skov).</para>
</listitem>
<listitem><para> FS : vfat (Sven Ottemann).</para>
</listitem>
<listitem><para> MISC : z2ram (Jesper Skov).</para>
</listitem>
<listitem><para> RAM : ram disk (initrd) (Jesper Skov).</para>
</listitem>
<listitem><para> PROTOCOLS: PPP (Carsten Pluntke).</para>
</listitem>
</itemizedlist>
</chapter>
<chapter id="problems"><title>Known Problems</title>
<para>There are still plenty of problems with &linapus;. Remember
it is a developer kernel, so you cannot expect everything (or
anything) to be working. It should get better as time goes by,
though.</para>
<para>The To Do list below is basically the list of known
problems. If you have anything to add to the list, or if any of
the listed devices are working for you, please let me
know.</para>
<sect1 id="todo"><title>To Do - Kernel</title>
<para>I work on things as my time permits. I have had bad
experiences (plural!) with fixing drivers for devices I don't
have myself - it takes too much time and energy, even when
someone owning such a device offers to run test kernels. Thus,
if you want to see a working driver for your hardware, you
really need to start hacking yourself.</para>
<para>This is a list of jobs that are up for grabs. If you want
to do it and you think it will take more than a couple of
days, please let me know so I can mark it to prevent
duplicated efforts.</para>
<itemizedlist>
<listitem><para> (<emphasis>free</emphasis>) If the &ados; ROM
is shadowed, it will eat 512kB RAM. It
<emphasis>might</emphasis> be possible to disable this
shadow mapping, but I don't feel like hacking on it myself
- it can be disabled manually in the Early Startup
Menu.</para>
</listitem>
<listitem><para> (<emphasis>free</emphasis>) &cpu603; support
is not as good as it should be. In
<filename>arch/ppc/kernel/head.S</filename> and
<filename>arch/ppc/mm/init.c</filename> the flag
<symbol>NO_RELOAD_HTAB</symbol> should be set but this
causes the kernel to hang at the moment. Probably some
tophys/tovirt oversigt in
<filename>head.S</filename>. </para>
</listitem>
<listitem><para> (<emphasis> Roman Zippel</emphasis>)
Merging the &amiboot; changes. We need someone to
maintain the &amiboot; program as Geert Uytterhoeven
does not have the time anymore. Presently I have put the
&linapus; required changes in <xref
linkend="sd-boothack">.</para>
</listitem>
<listitem><para> (<emphasis>free</emphasis>) A4000T/A4091 SCSI
drivers require the kernel to be compiled using segment
registers for memory mapping.</para>
<para>Page translations are cached in on-chip translation
lookaside buffers (TLBs). When a memory access is
attempted and the page information is not found in the
TLBs, a table lookup from main memory is required.</para>
<para> When the kernel is mapped with BATs, execution of
kernel code does not require looking up information about
individual pages as the entire kernel memory space is
mapped in one chunk.</para>
<para> As the kernel memory space used to hold the NCR53c7xx
SCSI scripts needs to be mapped as write-through rather
than write-back, per-page cache control is required. The
current kernel memory system does not mix BAT mappings
with segment register mappings, so kernels compiled after
980820 have to use segment register mappings only to
ensure that A4091/A4000T drivers work correctly.</para>
<para>Two things can be done about this; in the short term,
users who don't use the affected SCSI drivers can rebuild
the kernel using BATs for memory mapping (undef
<option>MAP_RAM_WITH_SEGREGS</option> in
<filename>arch/ppc/mm/init.c</filename>).</para>
<para> A proper long term solution for all users is kernel
support for a mixed mapping strategy. Either by mapping
the end of kernel space with segment registers and having
a special allocator to deal with it, or by re-mapping the
required pages with segment registers. The latter strategy
is in my opinion better as any overhead will only affect
the pages used for the SCSI driver scripts. Unfortunately
it will require (minor) driver changes. The former will
affect the entire region of memory mapped with segment
registers (which will be 1/4 of the available memory -
8-16MB on most systems).</para>
<para>I would like to work on this after the machine
dependencies have been cleaned up in &linux; 2.3, but I
see no reason to spend energy on it in the immediate
future (since the drivers are working and users without
the SCSI controllers can rebuild a kernel with BAT
mappings).</para>
</listitem>
</itemizedlist>
<para>Other issues:</para>
<itemizedlist>
<listitem><para><emphasis>Complete driver for the &cybppc;
onboard wide SCSI controller.</emphasis></para>
<para>Jes Sørensen is working on this.</para>
</listitem>
<listitem><para><emphasis>Complete integration in the &linppc;
source tree.</emphasis></para>
<para>Recompiling a &linapus; kernel will require special
patches for a long time to come. &linapus; relies on files
from both the <filename
class=directory>arch/m68k</filename> and <filename
class=directory>arch/ppc</filename> directories which
makes a clean merge with the main source tree problematic
at best. There is hope though; since &linapus; is not the
only port with this problem (sparc/ultrasparc,
mac/powermac) there has been discussions of introducing a
new "mach" hierarchy where sources specific to a given
machine (such as the &amiga;) can reside.</para>
<para> I will continue upgrading the patches to the latest
release kernels and work on integrating changes in both
<filename class=directory>arch/m68k</filename> and
<filename class=directory>ppc/arch</filename>. Jes will
probably be doing a lot of editing when it gets to the
time of implementing the mach hierarchy.</para>
</listitem>
<listitem><para><emphasis>Completing the LILO
port.</emphasis></para>
<para>Roman Zippel is working on LILO support for
&linapus;.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1><title>To Do - &thisdoc;</title>
<para> There have been a few suggestions for improving
&thisdoc; which require more time than I have at the moment -
or I simply don't think it's worth the effort.</para>
<para> If you want to write a section please do so in
SGML (have a look in <filename>faq.sgml</filename> to get an
idea of what is required). If you can't be bothered to do
that, just send plain text and I will set it up in
SGML. <emphasis>Do not send me HTML!</emphasis></para>
<para> Again, if you think writing a section will
stretch over a couple of days, please let me know so I can
fill in your name and prevent wasted effort.</para>
<itemizedlist>
<listitem><para> (<emphasis>free</emphasis>) A
section with boothack example configurations. (suggested
by Christophe Decanini)</para>
</listitem>
<listitem><para> (<emphasis>free</emphasis>) A
section with example memory files - I already put in the
section but it's empty as no one returned my request for
configurations... These might come in handy again since
the kernel will eventually support both BAT and SEG mapped
memory (since BATs are more efficient).</para>
<para> This section should also describe how the
memory system works on APUS (shadow mapping, missing
512KB, etc) - this should make it clear why memory files
are (well, have) been required. Also how to properly
calculate the values of a memory file.</para>
</listitem>
</itemizedlist>
</sect1>
</chapter>
<chapter id="help"><title>Reporting Problems/Getting Help</title>
<para>There are three "official" ways of reporting problems and
getting help. There may exist other news groups or mailing lists
dedicated to &cybppc;, &blzppc; and/or &linux;(/APUS) than the
ones described in this section. Don't expect any of the
developers to read those - reporting problems by any other media
than those described in this section is just as likely to be
successful as reporting them to your mother (my apologies to any
&linapus; hacking mothers out there :)</para>
<para>Before reporting a problem, please read the section about
etiquette!</para>
<sect1 id="etiquette"><title>Etiquette</title>
<para>Mention that you run &linapus; if you are posting a
generic &linux; question to the news group. Your problem may
be &linapus; specific and you will help other readers realize
that if you properly identify the &linux; port you are using.</para>
<para>To help others help yourself, always include as much
information about the problem as possible. See <xref
linkend="debug">.</para>
<para>Keep your postings in a positive and friendly tone and
don't expect the problem to be fixed right away. What is
likely to happen is that someone will suggest solutions to
your problem: you may be asked to try things you have already
attempted (but didn't mention - be very informative!), you may
be asked to test special versions of the kernel or the
application. It's not guaranteed that your problem will be
solved, but with a bit of luck it will be. Above all, be
patient, understanding and positive - the developers may be
working on other things, helping others with their problems,
trying hard to have a life, or simply be clueless about the
nature of your problem.</para>
<para>Do not send questions like "I cannot boot &linux; on my
&amiga;. What's wrong?". You cannot expect anyone to answer
such postings, especially because there's no way anyone can be
helpful without first making enquiries about your system -
save yourself and others the inconvenience: supply as much
information as possible.</para>
<para>Please don't spam the kernel list or the news group with
stories about how poor you think the &linapus; support is, or
how the developers lack dedication. The only thing you get out
of this is a bad reputation - it doesn't make it easier for us
to support devices we don't have.</para>
<para>The same goes for failing applications and/or generic
kernel problems; if none of the developers are using a
particular feature of the kernel or application it is hard to
ensure that it is working properly. Again, it's your
responsibility to help.</para>
<para> Please read existing documentation before
posting questions. Even though some helpful person will
probably answer a frequently asked question, it's impolite
(<emphasis>on your part</emphasis>) to expect others to
spend time helping you when you cannot be bothered to take
the help people have already offered you in form of FAQs,
manuals and previously answered questions. Start by looking
in the directory <filename
class=directory>/usr/doc/HOWTO</filename> on a &rh; machine
which may contain the answers you are looking
for. <emphasis>If possible, it's always a good idea to
search news group and kernel list archives for a solution to
your problem. See the links page (<xref
linkend="links">).</emphasis></para>
</sect1>
<sect1><title>The Usenet News Group</title>
<para>The Usenet News Group <ulink
url="news:comp.os.linux.m68k">comp.os.linux.m68k</ulink> is
read by many &amiga; users who use &linux;. It's a good
place to ask if you have simple questions about &linux; that
are specific to the &amiga; (see below for &linapus;
questions).</para>
<para>You can also ask more generic questions about the use of
&linux; even though you would probably be better off posting
to groups with more traffic and readers. Remember, &linux; is
available on many platforms - an application problem you have
is likely also to be a problem for, say, an ix86 (Intel)
user.</para>
<para>And there are <emphasis>tons</emphasis> of help to be
found in FAQs, HOWTOs and general &linux; documentation (see
<xref linkend="links">). If you are new to &linux; you might
even consider buying a book about &linux; usage - this is one
of the things that sets &linux; apart from &ados;; there are
so many users that there's commercial interest in supporting
it (with books and hot-line help).</para>
</sect1>
<sect1><title>The &linapus; Kernel List</title>
<para>If you have a problem that is specific to the &linapus;
installation, use of specific &linapus; packages, or if you
think you have found a problem with the &linapus; kernel
(i.e., a driver problem or a generic kernel problem), you
should mail to the &linapus; kernel mailing list.</para>
<para>You should describe how to repeat the problem. It's very
hard to debug something that cannot be seen. Some problems are
periodic or occur at random times in different applications,
which is not easy to repeat. In this case, include whatever
information you have in the posting.</para>
<para>You can follow the traffic on the kernel list via the news
gateway at <ulink
url="news://sunsite.auc.dk/sunsite.linux.apus">
news://sunsite.auc.dk/sunsite.linux.apus</ulink>. It's fast
and your mail box is not overburdened. You can also join the
list (send mail to <ulink
url="mailto:linux-apus-help@sunsite.auc.dk">
linux-apus-help@sunsite.auc.dk</ulink>).</para>
<para>You can post to the list at the address <ulink
url="mailto:linux-apus@sunsite.auc.dk">
linux-apus@sunsite.auc.dk</ulink>.</para>
</sect1>
<sect1><title>The &linapus; <emphasis>FAQ Contribution</emphasis>
Email Address</title>
<para>This is <emphasis>not</emphasis> the place to ask for
help. This address's usage should be restricted to sending the
maintainer FAQ submissions. Everything else should be posted
to the kernel list which has a wider audience.</para>
<para>At the &linm68k; domain &linapus; has kindly been given an
email alias <ulink
url="mailto:apus@linux-m68k.org">apus@linux-m68k.org</ulink>. This
will forward mails to whoever is maintaining &thisdoc; (at the
moment me, Jesper Skov).</para>
</sect1>
</chapter>
<chapter id="chap-faq"><title>Frequently Asked Questions</title>
<para>In this chapter you will find a list of frequently asked
questions. If you don't find the answer to your question, please
read <xref linkend="help">.</para>
<orderedlist>
<listitem><para><emphasis>How come my questions are not
answered?</emphasis></para>
<para> Perhaps nobody knows the answer, or the question is not
directly related to &linapus;. If the same problem is
reproducible under &linm68k; you would be better of asking
in a &linm68k; forum. If you don't experience the problem
under &linm68k; it is likely to be &linapus; specific; please
include this information when you post to the &linapus;
kernel list. Even though this doesn't improve the chances of
getting the problem fixed, the problem can be mentioned in
&thisdoc; so others will be aware of it.</para>
<para>Your question could already be answered somewhere in
&thisdoc; and nobody can be bothered to tell you this. Help
yourself; read the entire document - it is not that big. It
is also a good idea to search for the answer to your
question in the &linapus; kernel list archive.</para>
<para> If you find answers to your questions in unexpected
parts of this document or in the kernel list archive, please
let me know so I can update &thisdoc; for the benefit of the
next user with the same problem.</para>
</listitem>
<listitem><para><emphasis>Are there any &ados;
requirements?</emphasis></para>
<para> Yes. Even though the &linux; kernel in itself does not
use &ados;, booting the kernel relies on &p5;'s &cpuppc;
micro kernel.</para>
</listitem>
<listitem><para><emphasis>Is &linapus; binary compatible with
the other &cpuppc; &linux; ports?</emphasis></para>
<para> Yes. You can (AFAIK) use most software packages
precompiled for &linppc;. Some noteworthy exceptions are:
the X server (see below) and &amiga; or &linapus; specific
tools which you are not likely to find available from normal
&linppc; sites.</para>
</listitem>
<listitem><para><emphasis>How come not all &linm68k; supported
devices can be selected when
configuring?</emphasis></para>
<para> Because &linux; configuring at the moment is
architecture dependent. You have to move items from
<filename>arch/m68k/config.in</filename> into
<filename>arch/ppc/config.in</filename> or (even better)
into the <filename>Config.in</filename> in a driver
directory. If you do, please post the diff on the kernel
list.</para>
</listitem>
<listitem><para><emphasis>Are &cybppc; developer boards
supported?</emphasis></para>
<para> Not at the moment - and they are not likely to be
supported any time soon; moving the &cpum68k; CPU from one
board to another is hell and I <emphasis>hate</emphasis>
fiddling with the guts of my box. But if you have such a
beast, by all means, start porting - I can give you some
pointers.</para>
</listitem>
<listitem><para><emphasis>Is Netscape available?</emphasis></para>
<para> Yes. And it's even working (according to Jens Kristian
Jensen).</para>
</listitem>
<listitem><para><emphasis>Is the &cpum68k; CPU used for
anything?</emphasis></para>
<para> No. It is put to sleep (stop #2700) during boot. This
may change sometime in the future. I guess it could be used
as a gfx coprocessor, for clearing empty pages, or even for
running native &cpum68k; programs under special conditions
(like AROS).</para>
</listitem>
<listitem><para><emphasis>Will it ever be possible to use a
mixed set of &cpum68k; and &cpuppc;
executables?</emphasis></para>
<para> Not likely. This would require a shared memory
mapping. However, nothing is impossible - you go ahead!</para>
</listitem>
<listitem><para><emphasis>I can't boot from the ram disk with
2.1.90 kernels!?!</emphasis></para>
<para> There's some problem with identifying MINIX headers in
2.1.90. Use gzip to compress the ram disk and it will
work.</para>
</listitem>
<listitem><para><emphasis>Does &linapus; support kernel
debugging with &gdb;?</emphasis></para>
<para> The kernel <emphasis>diff</emphasis> contains the
necessary stubs and config flag
(<symbol>CONFIG_KGDB</symbol>) to do this (originally for
PMAC, written by Mike Tesch). A debug kernel is around 10MB
though so I will not upload a precompiled kernel with
debugging. I have still not tested this so your mileage may
vary.</para>
</listitem>
<listitem><para><emphasis>When I recompile the kernel using your
patches, I get disk failures and runtime
errors!?!</emphasis></para>
<para> Use binutils-2.9.1 and egcs-1.1. Get the 980525
kernel sources or newer and you should be OK.</para>
</listitem>
<listitem><para><emphasis>Why not use LPSTOP to halt the
CPU on &cpu060; systems?</emphasis></para>
<para> It hangs the system. Possibly because the &cybppc; bus
design cannot cope with the signals the &cpu060; sends out
before powering down.</para>
</listitem>
<listitem><para><emphasis>I cannot mount all my
partitions. There are not enough dev nodes in the ram
disk!?!</emphasis></para>
<para> I have put <application>mknod</application> compiled
for &cpuppc; in <xref linkend="sd-misc">. Put it on an
&ados; partition you can mount, boot the kernel, mount the
&ados; partition, use <application>mknod</application> to
make new nodes.</para>
</listitem>
<listitem><para><emphasis>My system just hangs when I start
&boothack;!??</emphasis></para>
<para> It might be a problem with &boothack;. Try rebooting
the machine and run the tool
<application>bootmesg</application>. It should find a
progress string from the booter. This string is deleted by
the kernel if it boots, so if the string is not found, it's
probably a kernel problem (and you should use
<option>debug=mem</option> and &dmesg; instead).</para>
<para> The last character stored before jumping to the kernel
is 'K'. If you see a string, and the last letter is not 'K',
you can look in the <filename>ppc_boot.c</filename> code to
get an idea of where things go wrong. Please also report
your findings.</para>
<para> Another thing that is likely to cause this problem is
memory. See <xref linkend="booting"> for some more
information on this point.</para>
<para> Yet another common cause is wrong video mode
parameters. <option>'vga'</option> has caused problems,
while specifying none (if your monitor can handle it)
definitely works. If you have a CyberVision you have to let
it be initialized by CyberGfx before you boot.</para>
<para> You must also disable Shadow ROM in the &cybppc; or
&blzppc; Early Startup Menu and set the memory speed to
70ns.</para>
<para> Finally, make sure to put &boothack;
options (starts with a dash (-)) first on the line and
kernel options (no dash) last on the line when booting the
kernel.</para>
</listitem>
<listitem><para><emphasis>Can I boot from a soft kicked
system?</emphasis></para>
<para> Possibly. You might be able to make it
work. Do try it. If it doesn't work you have to disable
the soft kicked ROM. You might also try booting your
machine without <filename>startup-sequence</filename>, run
<application>setpatch</application> and then start
&linapus; (unless you have a CyberVision in which case you
must let CyberGfx initialize it first).</para>
</listitem>
<listitem><para><emphasis>Can I compile my own kernels under
&linapus;?</emphasis></para>
<para> Yes. I have successfully run a kernel I build with
binutils-2.9.1 and egcs-1.1 on my &linapus; box. However,
YMMV.</para>
</listitem>
<listitem><para><emphasis>I get rejects when applying your
patch!!??</emphasis></para>
<para> My patches are relative to the
<emphasis>release</emphasis> versions of the &linm68k;
kernel sources (not Linus' kernel sources!). If you apply
&linm68k; patches from the &linm68k; kernel list before you
apply my patches, you may get conflicts.</para>
</listitem>
<listitem><para><emphasis>I cannot boot &linapus; on my
&blzppc;!!?</emphasis></para>
<para><emphasis>Hint from Sinan Gurkan</emphasis></para>
<para> The later firmware versions make the
hardware identify itself as if it had a SCSI controller -
even the boards with no SCSI controller! Until the problem
gets properly fixed, you can press <keycap>s</keycap>
during boot to disable the (non-existing) SCSI hardware
:)</para>
</listitem>
<listitem><para> <emphasis>How do I boot with AGA
display on a machine with
CyberVision(/3D)?</emphasis></para>
<para>You need to disable the frame buffer device assigned to
the graphics card by adding (one of) the below to the boot
options.</para>
<screen>
video=cyber:off
video=virge:off</screen>
</listitem>
<listitem><para> <emphasis> How do I change the
default keymap?</emphasis></para>
<para><emphasis>Text by Marco De Vitis</emphasis></para>
<para> Let's assume you already have a keymap file
that suits your system,
e.g. <filename>amiga-it.map</filename> for an Italian
Amiga keyboard (you can find many keymap files at
<ulink
url="ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/">
ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/</ulink>).
Put this file in the <filename
class="directory">/usr/lib/kbd/keytables</filename>
directory. You should now be able to load it by issuing
this command:</para>
<screen>
loadkeys amiga-it.map </screen>
<para> To have it loaded during boot (on &rhppc;),
you have to edit the
<filename>/etc/sysconfig/keyboard</filename> file so that
it contains the full path to your keymap; by default, it
should read something like
"/usr/lib/kbd/keytables/amiga-us.map", so you usually only
need to change the ending.</para>
</listitem>
<listitem><para> <emphasis> How come the sound
driver is not included in the prebuilt
kernels?</emphasis></para>
<para> Because it doesn't like the heartbeat
(which affects the filter when blinking the
led). Heartbeat is important for determining if &linapus;
has properly booted even if the display is blank, i.e.,
it is relevant in a kernel that a novice will boot
for the first time. And it means I don't have to switch
display each time I boot a kernel ;)</para>
<para> If you worry about sound support, it means
you have a stable system -- and that means that you should
be able to rebuild the kernel yourself.</para>
</listitem>
<listitem><para> <emphasis> Why can't the mailing
list...?</emphasis></para>
<para> It's not by accident that the list server
is set up as it is -- this is the way the guys in power
like it :) See below for some workarounds.</para>
<para> SUBJECT LINE: If you want [APUS] or similar
in the subject line, it's probably because you want to
sort/filter your mail by subject. In that case, your
mailer should be able to sort/filter by any other header
line. A good one is:</para>
<screen>
Mailing-List: contact linux-apus-help@sunsite.auc.dk; run by ezmlm </screen>
<para> REPLY-TO: Yes, you 'reply' to the author of
the article. We are all real living people -- if you want
to reply to something it's because you want to say
something to the dude at the other end of the damp string,
no? :) Polite people mostly CC: the list so others can
benefit from the reply as well. So, use 'followup' instead
of 'reply'. Yes, the receiver gets two copies; that is
The-Way-It-Should-Be(TM).</para>
</listitem>
</orderedlist>
</chapter>
<chapter id="history"><title>History</title>
<para>I like to follow the progress of the stuff I use, so I
decided to keep track of &linapus; changes so others with the
same interest can get an idea of what's happening.</para>
<para>I also try to keep a source code <ulink
url="ChangeLog.APUS">ChangeLog</ulink> for the &linapus;
changes which is available from <xref
linkend="sd-docs">.</para>
<para>
<emphasis>date990322 990322</emphasis>
<itemizedlist>
<listitem><para>Added mb() fix for A2091 driver from
Jes.</para>
</listitem>
</itemizedlist>
<emphasis>date990321 990321</emphasis>
<itemizedlist>
<listitem><para>Added yet another info item for GPM, this
time from Gerard Cornu.</para>
</listitem>
<listitem><para>ChangeLog now available from this
document. Incremental change logs included in the
<filename>linux-apus-YYMMDD.diff</filename> diffs as a
comment.</para>
</listitem>
</itemizedlist>
<emphasis> 990301</emphasis>
<itemizedlist>
<listitem><para>Ken Tyler sends me a virge blitter fix as a
birthday present ;)</para></listitem>
</itemizedlist>
<emphasis> 990221</emphasis>
<itemizedlist>
<listitem><para>Arno Griffioen takes matters in his own
hands and fixes DMA on the A3000 SCSI controller
:)</para>
</listitem>
<listitem><para>I added the same DMA patches to the A2091
and GVP11 drivers.</para>
</listitem>
</itemizedlist>
<emphasis> 990220</emphasis>
<itemizedlist>
<listitem><para>Updated to &linm68k; 2.2.1pre2.</para>
</listitem>
<listitem><para>Cleaned up serial driver and GDB support.</para>
</listitem>
</itemizedlist>
<emphasis> 990214</emphasis>
<itemizedlist>
<listitem><para>Added <application>gpm</application> note
from Robert Ramiega.</para></listitem>
</itemizedlist>
<emphasis> 990206</emphasis>
<itemizedlist>
<listitem><para>Updated to &linm68k; 2.2.1pre1.</para>
</listitem>
<listitem><para>Removed parallel/printer drivers. The new
driver scheme seems to hang the kernel and I don't have
the time to track it down now.</para>
</listitem>
</itemizedlist>
<emphasis> 990203</emphasis>
<itemizedlist>
<listitem><para>Updated &thisdoc; to compile with DocBook
3.0</para></listitem>
</itemizedlist>
<emphasis> 990201</emphasis>
<itemizedlist>
<listitem><para>Debian install help updated (Michel
Dänzer)</para>
</listitem>
<listitem><para>Added Virge Z2 support from (Christian
T. Steigies).</para>
</listitem>
</itemizedlist>
<emphasis> 990131</emphasis>
<itemizedlist>
<listitem><para>NO_RELOAD_TAB fix from Michel Dänzer.</para>
</listitem>
<listitem><para>Cleaned up APUS: output during boot.</para>
</listitem>
</itemizedlist>
<emphasis>990129</emphasis>
<itemizedlist>
<listitem><para>Virge update from Ken Tyler.</para>
</listitem>
<listitem><para>Other video updates from Geert Uytterhoeven.</para>
</listitem>
</itemizedlist>
<emphasis> 990123</emphasis>
<itemizedlist>
<listitem><para>Module fix from Andreas Schwab.</para>
</listitem>
<listitem><para>Menuconfig and module fix from Michel
Dänzer).</para>
</listitem>
<listitem><para>Rewrote part of the interrupt handling. Lvl7
interrupts cannot be avoided, but they are now treated
as the bogus Lvl0 interrupts.</para>
</listitem>
</itemizedlist>
<emphasis> 990118</emphasis>
<itemizedlist>
<listitem><para>Updated to &linm68k; 2.2.0pre7.</para>
</listitem>
<listitem><para>Replaced the obsolete cvppc driver with the
pm2 driver (Ilario Nardinocchi).</para>
</listitem>
<listitem><para>Fix BlizzardPPC SCSI's dependencies (Michel
Dänzer).</para>
</listitem>
<listitem><para>Replaced iobarrier() with mb().</para>
</listitem>
</itemizedlist>
<emphasis> 990113</emphasis>
<itemizedlist>
<listitem><para>Added fix for building lp as module
from Frank Petzold.</para>
</listitem>
<listitem><para>Removed FastLane from list of working
hardware and from the precompiled kernels.</para>
</listitem>
</itemizedlist>
<emphasis>990112</emphasis>
<itemizedlist>
<listitem><para>Added &debian; installation section by
Michel Dänzer.</para>
</listitem>
</itemizedlist>
<emphasis> 990111</emphasis>
<itemizedlist>
<listitem><para>Updated to &linm68k; 2.2.0pre6. There might
be problems with memory mapping devices. If you
experience problems, try using the nobats option.</para>
</listitem>
</itemizedlist>
<emphasis> 990106</emphasis>
<itemizedlist>
<listitem><para>Added PowerUp PCI Bridge detection to
boothack. Contributed by Ralph Schmidt.</para>
</listitem>
</itemizedlist>
<emphasis> 990105</emphasis>
<itemizedlist>
<listitem><para>Updated to &linm68k; 2.2.0pre4. Light my
fire, baby! It's smoooking fast :@) &x; starts in no
time now... I need to get this kernel installed on
Concubine!</para>
</listitem>
<listitem><para>Changed installer directory structure on
&sunsite; in preparation for proper support of &debian;
installation schemes.</para>
</listitem>
<listitem><para>Martin Koenig sez the Ariadne II driver is
working (somewhat slow though).</para>
</listitem>
<listitem><para>Carlos Mayo sez the SurfSquirrel is working.
(PCMCIA card, right?).</para>
</listitem>
<listitem><para>Updated &thisdoc; here and there. If I
missed anything during the past couple of weeks, please
let me know.</para></listitem>
</itemizedlist>
<emphasis> 981216</emphasis>
<itemizedlist>
<listitem><para>Updated to &linm68k; 2.1.131.</para>
</listitem>
</itemizedlist>
<emphasis> 981213</emphasis>
<itemizedlist>
<listitem><para>Added patch from Richard Hirst to fix CDROM
mount problem on A4000T/A4091 SCSI.</para>
</listitem>
<listitem><para>Changed CONFIG_PPC in sound driver to
CONFIG_PMAC. I'd like to know if it solves the
problems.</para>
</listitem>
</itemizedlist>
<emphasis> 981129</emphasis>
<itemizedlist>
<listitem><para>Added a handful of patches from Chris
Lawrence.</para>
</listitem>
</itemizedlist>
<emphasis> 981127</emphasis>
<itemizedlist>
<listitem><para>Updated to 2.1.130</para>
</listitem>
<listitem><para>Fixed off-by-1 error in reloc code. This is
what stopped some people from running the later kernels,
I'm sure.</para>
</listitem>
<listitem><para>Added a (good) handful of iobarriers to the
MFC serial driver. It might have fixed the reported
problem.</para>
</listitem>
</itemizedlist>
<emphasis> 981126</emphasis>
<itemizedlist>
<listitem><para>The <filename
class="directory">latest</filename> directory now
contains files (not links) with dated names to prevent
confusion in the future. If people try to download
using a cached and obsolete name, they should get an
error.</para>
</listitem>
<listitem><para>Reintroduced the <filename>head.S</filename>
progress values.</para>
</listitem>
</itemizedlist>
<emphasis> 981125</emphasis>
<itemizedlist>
<listitem><para>Included Whippet driver. I got a patch from
Carlos Mayo some time ago, but it was already included
in 2.1.127.</para>
</listitem>
<listitem><para>Changed a few bits of the new relocation
magic per suggestion from Paul Mackerras. I can't
imagine it will help on the failing boxes but one never
knows.</para>
</listitem>
<listitem><para>Added new sections by Marco (FAQ) and
Matthias (X).</para>
</listitem>
</itemizedlist>
<emphasis> 981122</emphasis>
<itemizedlist>
<listitem><para>Added some &debppc; links from Sven Luther</para>
</listitem>
<listitem><para>Updated list of included drivers.</para>
</listitem>
<listitem><para>The vger integration is pretty much done
now.</para>
</listitem>
<listitem><para>Reports of 981121 failing to boot. *sigh* If
you can get it to boot, use an older kernel.</para>
</listitem>
</itemizedlist>
<emphasis> 981121</emphasis>
<itemizedlist>
<listitem><para>Added X help text from Marco De Vitis.</para>
</listitem>
<listitem><para>Good progress on the major &linapus;
workover and vger integration. It's now close to being
possible to boot a &linapus; kernel on any of the other
PPC targets. Do I need to point out that this is a Good
Thing(TM) for distributions? :) Still a few nits to
sort out though.</para>
</listitem>
<listitem><para>&boothack; needed a modification to allow
the above changes so you need to get that as well. It is
backwards compatible, so you can still use it with the
older kernels.</para></listitem>
<listitem><para>Included pretty much all drivers in the
kernel image (and Mac FS and partition table support).</para>
</listitem>
</itemizedlist>
<emphasis> 981117</emphasis>
<itemizedlist>
<listitem><para>Worked on vger integration.</para>
</listitem>
</itemizedlist>
<emphasis> 981114</emphasis>
<itemizedlist>
<listitem><para>Renamed iobarrier macros.</para>
</listitem>
<listitem><para>Updated CyberVision driver. Might have
broken it, please let me know.</para>
</listitem>
<listitem><para>Cleaned up links (see <xref
linkend="links">).</para></listitem>
</itemizedlist>
<emphasis> 981112</emphasis>
<itemizedlist>
<listitem><para>Replaced auxmem with a simpler hack. Even
though auxmem would have been pretty compared with the
random hacking of Z2 and motherboard memory now used, it
would also have been overkill.</para>
</listitem>
<listitem><para>Updated to 2.1.127.</para>
</listitem>
</itemizedlist>
<emphasis> 981108</emphasis>
<itemizedlist>
<listitem><para>Added section about installing from a &rhrc;
CD.</para></listitem>
<listitem><para>Included Ilario's CVPPC frame buffer
device. See the home page for details on use (<xref
linkend="links-linux">).</para>
</listitem>
</itemizedlist>
<emphasis> 981107</emphasis>
<itemizedlist>
<listitem><para>Sync'd with vger again. Mainly to get some
&linapus; changes into the &linux; main tree.</para>
</listitem>
<listitem><para>Juiced up my motivation (nice meeting you,
Ken & Julian :)</para>
</listitem>
<listitem><para>Fixed stupid bug in mm_ptov. Found by
Ilario.</para>
</listitem>
<listitem><para>Redid the fb X fix, avoiding ptov
calls.</para>
</listitem>
</itemizedlist>
<emphasis> 981105</emphasis>
<itemizedlist>
<listitem><para>Added '60nsram' kernel option.</para>
</listitem>
<listitem><para>Added 'nobats' kernel option.</para>
</listitem>
<listitem><para>Improved memory mapping; should use BATs
correctly, even on &blzppc; cards with weird
alignment.</para>
</listitem>
</itemizedlist>
<emphasis> 981103</emphasis>
<itemizedlist>
<listitem><para>Added patch from Peter McGavin to fix EGS.</para>
</listitem>
<listitem><para>Added patch from Frank Petzold to fix
modules.</para>
</listitem>
<listitem><para>Worked a bit more on &thisdoc;</para>
</listitem>
</itemizedlist>
<emphasis> 981102</emphasis>
<itemizedlist>
<listitem><para>Sync'd PPC stuff with vger.</para>
</listitem>
<listitem><para>Proper fix to the X problem.</para>
</listitem>
<listitem><para>Started rearranging &thisdoc; into two parts.</para>
</listitem>
</itemizedlist>
<emphasis> 981031</emphasis>
<itemizedlist>
<listitem><para>Added IDEDOUBLER fix from Geert Uytterhoeven.</para>
</listitem>
<listitem><para>Added X fix from Carsten.</para>
</listitem>
<listitem><para>Added some installer doc changes from Ken
Tyler.</para>
</listitem>
</itemizedlist>
<emphasis>981018</emphasis>
<itemizedlist>
<listitem><para>Sven found the problem preventing proper
operation on Blizzard. It was as suspected all along
related to the new (soon obsolete :) booting
process.</para>
</listitem>
<listitem><para>I have started using egcs-1.1 for building
kernels. They seem to work fine on my box. I'd like to
hear from you ASAP if they don't work on your box.</para>
<para>I don't know if the patches <xref linkend="sd-misc">
are necessary for egcs-1.1. I guess time will
tell. (Remember; if parts of the patch seems to be missing
in egcs-1.1 it doesn't necessary mean that the problem the
patch fixed in 1.0.3 hasn't been fixed in some other
way.)</para>
</listitem>
<listitem><para>Included the serial driver again.</para>
</listitem>
</itemizedlist>
<emphasis> 981014</emphasis>
<itemizedlist>
<listitem><para>Added &rh; install updates from Ken Tyler to
&thisdoc;</para>
</listitem>
</itemizedlist>
<emphasis>981009</emphasis>
<itemizedlist>
<listitem><para>Updated to 2.1.124 (X is still broken).</para>
</listitem>
</itemizedlist>
<emphasis>981005</emphasis>
<itemizedlist>
<listitem><para>Included Fastlane SCSI driver.</para>
</listitem>
</itemizedlist>
<emphasis>981004</emphasis>
<itemizedlist>
<listitem><para>Wasted some more time on KGDB. It's still not
good, but it's better.</para>
</listitem>
<listitem><para>Added heartbeat.</para>
</listitem>
</itemizedlist>
<emphasis>981003</emphasis>
<itemizedlist>
<listitem><para>Made KGDB work (still some problems to sort
out, but it is usable).</para>
</listitem>
<listitem><para>Added workaround for ioremap bug. You can now
use motherboard/Z2 memory for swap (see relevant FAQ
entry).</para>
</listitem>
<listitem><para>Added compiler option (-fno-strength-reduce)
that may (or may not) affect the A4000T/A4091 SCSI
drivers.</para>
</listitem>
</itemizedlist>
<emphasis>981002</emphasis>
<itemizedlist>
<listitem><para>Added some more changes to the &rh; installer
sections from Ken Tyler.</para>
</listitem>
</itemizedlist>
<emphasis> 980926</emphasis>
<itemizedlist>
<listitem><para>Included some changes to the &rh; installer
sections from Ken Tyler.</para>
</listitem>
<listitem><para>Added new FAQ entry from Ken Tyler
(disabling CV to boot on AGA).</para>
</listitem>
<listitem><para>Added new section with suggestions for
&thisdoc;</para>
</listitem>
<listitem><para>Christophe Decanini reports that RH CDROM, FTP
and NFS installation methods work.</para>
</listitem>
</itemizedlist>
<emphasis> 980915</emphasis>
<itemizedlist>
<listitem><para>Added Geert Uytterhoeven's patch to allow
1024x768-16bp with CyberVision.</para>
</listitem>
</itemizedlist>
<emphasis> 980912</emphasis>
<itemizedlist>
<listitem><para>Undid the first change of 980907 since it made
the kernel fail to boot on most other machines.</para>
</listitem>
</itemizedlist>
<emphasis>980908</emphasis>
<itemizedlist>
<listitem><para>Updated to 2.1.120.</para>
</listitem>
</itemizedlist>
<emphasis>980907</emphasis>
<itemizedlist>
<listitem><para>Only 128kB is eaten by the PPC exception
registers now, leaving 384kB more free memory than
before.</para>
</listitem>
<listitem><para>Added a simple and not yet fully functional
method for using motherboard memory as swap. See new FAQ
entry.</para>
</listitem>
</itemizedlist>
<emphasis>980902</emphasis>
<itemizedlist>
<listitem><para>Submitted patch to vger (well, to Geert,
really :)</para>
</listitem>
<listitem><para>Added code to determine bus speed written by
Ralph Schmidt.</para>
</listitem>
</itemizedlist>
<emphasis>980901</emphasis>
<itemizedlist>
<listitem><para>Added latest vger PPC changes.</para>
</listitem>
<listitem><para>The above bloated the kernel so much that a
linker/booter problem prevented it from booting. I removed
the Retina and clGen graphics drivers because of
this.</para>
</listitem>
</itemizedlist>
<emphasis>980831</emphasis>
<itemizedlist>
<listitem><para>It's now possible to disable wait states for
all bus speeds. Sven Ottemann has been pushing for this
for some time, but let me warn you; you need 60ns RAM, and
according to Phase5 it doesn't work on 66MHz
buses. YMMV.</para>
</listitem>
<listitem><para> Now the bus speed ID is output at
startup to help debugging.</para>
</listitem>
</itemizedlist>
<emphasis>980830</emphasis>
<itemizedlist>
<listitem><para>Sven Ottemann fixed the booter to be a
one-file image, rather than the old ADOSHUNK/ELF
pair.</para>
</listitem>
<listitem><para>Made the booter clear all MMU
registers. <filename>head.S</filename> now sets up all the
required mappings - which makes the &blzppc; get past the
old trouble spot. There are still some problems left
though.</para>
</listitem>
<listitem><para>Reintroduced colors to &thisdoc;, marking new
stuff. The chapters and sections are appended with a date
where appropriate so you can see where the latest changes
are from the table of contents.</para>
</listitem>
</itemizedlist>
<emphasis> 980829</emphasis>
<itemizedlist>
<listitem><para>Updated to &linux; 2.1.119.</para>
</listitem>
</itemizedlist>
<emphasis> 980827</emphasis>
<itemizedlist>
<listitem><para> Fixed a potential problem in
<filename>head.S</filename>. &blzppc; owners should give
it a try.</para>
</listitem>
</itemizedlist>
<emphasis>980822</emphasis>
<itemizedlist>
<listitem><para> Ken Tyler informs me that the A4091/A4000T
SCSI driver is finally working. This is due to the
fabulous work of Richard Hirst. Still, this has resulted
in an item on the to do list (performance
penalty).</para>
</listitem>
<listitem><para> I have put my sources under CVS control so in
the future I will be able to release incremental diffs of
the &linapus; sources.</para>
</listitem>
</itemizedlist>
<emphasis>980821</emphasis>
<itemizedlist>
<listitem><para> Francisco also reports that the Hydra driver
is working. </para>
</listitem>
<listitem><para> &blzppc; owners should check the FAQ entry
specific to their HW. I just added a suggestion from Sven
Luther.</para>
</listitem>
</itemizedlist>
<emphasis>980820</emphasis>
<itemizedlist>
<listitem><para> Francisco Sepulveda informs me that the
Picasso driver is working on his A3000T.</para>
</listitem>
<listitem><para> Added patch to menubox.c from Frank Petzold.</para>
</listitem>
<listitem><para> Changed kernel to use segment registers for
mapping kernel space. This might fix the A4000T/A4091
driver problem (even though I'm tired of being
enthusiastic about that :)</para>
</listitem>
</itemizedlist>
<emphasis>980816</emphasis>
<itemizedlist>
<listitem><para> Completed move of &thisdoc; to DocBook. That
took some time!</para>
<para> I wonder if anyone will miss the color highlighting
of changes to the document? If so, let me know and I will
get it working again.</para>
</listitem>
<listitem><para> Added some changes from &linppc;</para>
</listitem>
</itemizedlist>
<emphasis>980813</emphasis>
<itemizedlist>
<listitem><para> Included &blzppc; SCSI driver again.</para>
</listitem>
<listitem><para> Included Buddha IDE driver.</para>
</listitem>
<listitem><para> Included patch to socket.h</para>
</listitem>
</itemizedlist>
<emphasis>980812</emphasis>
<itemizedlist>
<listitem><para>Included clgen gfx driver.</para>
</listitem>
<listitem><para>More additions to the A4091 support.</para>
</listitem>
<listitem><para>Updated to linux-2.1.115</para>
</listitem>
</itemizedlist>
<emphasis>980801</emphasis>
<itemizedlist>
<listitem><para> Unfortunately the new &boothack; still can't
boot &linapus; properly on &blzppc; - possibly a problem
with the 040. I'd like to hear from &cybppc; people who
can boot on an 040.</para>
</listitem>
<listitem><para> Added a few syncs and eieios to the
booter.</para>
</listitem>
<listitem><para> Added Sven's Blizzard SCSI patches. The
kernel image in vmbl980801.lzh includes this driver and a
not the Gayle IDE driver which conflicts with the SCSI
driver for some reason.</para>
</listitem>
</itemizedlist>
<emphasis>980730</emphasis>
<itemizedlist>
<listitem><para> &boothack;: Added more robust synchronization
between the CPUs (the "wedgie" scheme).</para>
</listitem>
<listitem><para> &boothack;: Added stack space for &cpuppc; in
CHIP.</para>
</listitem>
<listitem><para> &boothack;: Invalidate cache contents.</para>
</listitem>
<listitem><para> &boothack;: Disable TimerBase interrupts
(this is the one that won the gold).</para>
</listitem>
<listitem><para> The above ensures rock-stable booting on my
box with the 980711 ppc.library. No more bad checksums;
it's just awesome :)</para>
</listitem>
</itemizedlist>
<emphasis>980726-2</emphasis>
<itemizedlist>
<listitem><para> Updated my ppc.library to 980711. I now know
what the problem has been on the &blzppc; cards - I think
:)</para>
</listitem>
<listitem><para> Moved head.S progress word to 0xfff0eff0.</para>
</listitem>
<listitem><para> Added some text about how to avoid memory
problems when booting (Please <emphasis>do</emphasis> read
it and tell me if it is of any help, or if it requires
changes/additions).</para>
</listitem>
<listitem><para> Added checksum code to the booter.</para>
</listitem>
</itemizedlist>
<emphasis>980726</emphasis>
<itemizedlist>
<listitem><para> Fixed the problem with zorro devices count.</para>
</listitem>
<listitem><para> Fixed memory initialization code again.</para>
</listitem>
</itemizedlist>
<emphasis>980725</emphasis>
<itemizedlist>
<listitem><para> Fixed silly bug in an A4091/A4000T SCSI
driver support routine which caused kernel panics.</para>
</listitem>
<listitem><para> Thomas Lohmann informs me that Ken&Son's
&rhinstaller; works with FTP.</para>
</listitem>
<listitem><para> Added new contrib directory at &sunsite; (see
<xref linkend="sunsite">).</para>
</listitem>
<listitem><para> Memory initialization should now correctly
identify an active &ados; ROM shadow and ignore that 512kB
block of memory.</para>
</listitem>
</itemizedlist>
<emphasis>980724</emphasis>
<itemizedlist>
<listitem><para> Changed date format to YYMMDD.</para>
</listitem>
<listitem><para> Fixed problem with Zorro structures (get
newest &boothack;).</para>
</listitem>
</itemizedlist>
<emphasis>980723</emphasis>
<itemizedlist>
<listitem><para> Apparently lots of stuff is broken in
2.1.108: CyberVision, GVP HC+8, you name it. I'm
clueless. Nothing really changed on the &linapus; side of
things, so I must have missed some serious &linm68k;
changes.</para>
</listitem>
<listitem><para> Thomas Lohmann informs me that CV works with
the console in all resolutions after he installed the
ppc.library included in cybergfx of 05.07.98
(IIRC).</para>
</listitem>
<listitem><para> I tried including sound in the kernel, but
there is a build problem.</para>
</listitem>
<listitem><para> I have made some changes to the A4091/A4000T
driver support that might make a difference.</para>
</listitem>
</itemizedlist>
<emphasis>980719</emphasis>
<itemizedlist>
<listitem><para> Added Richard Hirst's 53c710 patch.</para>
</listitem>
</itemizedlist>
<emphasis>980711</emphasis>
<itemizedlist>
<listitem><para> Moved patches to 2.1.108.</para>
</listitem>
<listitem><para> Added a few FAQ changes suggested by Thomas
Lohmann. He also told me that the GVP A2000-HC+8 Series II
SCSI controller is working with &linapus;.</para>
</listitem>
</itemizedlist>
<emphasis>980710</emphasis>
<itemizedlist>
<listitem><para> Increased SCSI timeouts.</para>
</listitem>
<listitem><para> Tested &linapus; startup with ppc.library
version 46.15 and 68060.library version 44.3. No problems
whatsoever on my box.</para>
</listitem>
</itemizedlist>
<emphasis>980707</emphasis>
<itemizedlist>
<listitem><para> Massimo Gais has made a mirror of the apus
directory at ftp.unina.it.</para>
</listitem>
</itemizedlist>
<emphasis>980617</emphasis>
<itemizedlist>
<listitem><para> Reordered the sections in the installation
chapter.</para>
</listitem>
<listitem><para> Changed the booter to disable ROM
mappings. Maybe it will help on &blzppc; cards?</para>
</listitem>
</itemizedlist>
<emphasis>980616</emphasis>
<itemizedlist>
<listitem><para> I have run of ideas for what could be causing
the &blzppc; problem. Someone with a &blzppc;s needs to
dig in and have a look. I'm not spending any more time on
this....</para>
</listitem>
<listitem><para> Ken and Julian Tyler have completed the
&rhinstaller; support for &linapus;. Obviously this makes
it <emphasis>much</emphasis> easier to get a system
properly installed and working.</para>
</listitem>
</itemizedlist>
<emphasis>980615</emphasis>
<itemizedlist>
<listitem><para> &sunsite; has been unaccessible for a couple
of days now. It's due to a cut cable on the Danish back
bone (I think).</para>
</listitem>
<listitem><para> Bartek Kozakiewicz tells me that HFS and
ISO9660/Joliet drivers are working. And also that the
printer driver is working.</para>
</listitem>
</itemizedlist>
<emphasis>980612</emphasis>
<itemizedlist>
<listitem><para> Now writes head.S progress to
0xfff07000. Hope it works this time... *sigh*</para>
</listitem>
<listitem><para> Cleaned up &linapus; changes to intrude less
on the &linm68k; sources.</para>
</listitem>
</itemizedlist>
<emphasis>980610</emphasis>
<itemizedlist>
<listitem><para> Carsten Plunkte tells me it is important to
apply the egcs patches from &sunsite; if building
applications (I added a new subsection to
Applications).</para>
</listitem>
</itemizedlist>
<emphasis>980609</emphasis>
<itemizedlist>
<listitem><para> Moved patches to 2.1.105.</para></listitem>
<listitem><para> Geert Uytterhoeven tells me that emacs-nox
also fails on CHRP so it is indeed an application
problem.</para>
</listitem>
</itemizedlist>
<emphasis>980607</emphasis>
<itemizedlist>
<listitem><para> Updated ppc.library to V45.20. Everything is
still working. Also tried installing another 8MB but the
ppc.library (V44.27) wouldn't run then. I might try
installing the RAM again with the new ppc.library at some
time.</para>
</listitem>
<listitem><para> Corrected initial mapping in head.S - I had
set it to 4MB, not 8MB.</para>
</listitem>
<listitem><para> Now writes head.S progress to address
0xfff02ffc which exists on all PoweUp boards and is not
deleted by the &p5; &cpuppc; software (not on my box
anyway).</para>
</listitem>
</itemizedlist>
<emphasis>980606</emphasis>
<itemizedlist>
<listitem><para> The emacs compiled with X libs works, so I
think the problem with emacs-nox is probably a generic
(application) problem, and not caused in particular by the
&linapus; kernel.</para>
</listitem>
<listitem><para> More reports of problems booting the newest
kernels. I'm at a loss here - the kernels are working fine
on my box.</para>
</listitem>
</itemizedlist>
<emphasis>980604</emphasis>
<itemizedlist>
<listitem><para> Merged in a few vger changes and submitted
the few &linapus; changes to the vger tree.</para>
</listitem>
</itemizedlist>
<emphasis>980603</emphasis>
<itemizedlist>
<listitem><para> I replaced the head.S serial progress output
with a counter updated in memory. If the kernel hangs for
you before it opens a display, have a look at address
0xfff04000 after rebooting. The long word should read
0x1234000?, with ? being between 1 and 8.</para>
</listitem>
</itemizedlist>
<emphasis>980601</emphasis>
<itemizedlist>
<listitem><para> SCSI drivers are now again included in the
precompiled kernels.</para>
</listitem>
</itemizedlist>
<emphasis>980528</emphasis>
<itemizedlist>
<listitem><para> Exception registers are now mapped with
caching enabled.</para>
</listitem>
<listitem><para> The kernel can now reboot the machine (thanks
to Holger Jakob who bugged Ralph Schmidt for the
information.)</para>
</listitem>
<listitem><para> The kernel should now be able to handle weird
aligned memory (such as 24MB aligned to an 8MB
boundary).</para>
</listitem>
<listitem><para> While working its way through head.S (early
initialization) the kernel now writes the characters A-F
to the serial port much like &linm68k;. Caching issues
prevents it from being just as detailed as in &linm68k;
though.</para>
</listitem>
<listitem><para> Removed BOOTP/RARP support.</para>
</listitem>
</itemizedlist>
<emphasis>980527</emphasis>
<itemizedlist>
<listitem><para> Found potential cause of the &blzppc;
problems; the first mapping set up before the memory
system is initialized used a 64MB mapping instead of the
16MB mentioned in the comment. I changed it to 8MB which
should allow a &blzppc; box with only 8MB to boot
&linapus;.</para>
</listitem>
<listitem><para> Included support for msdos partition tables.</para>
</listitem>
<listitem><para> Put some patches for egcs-1.0.3 in the misc
directory at &sunsite;. I don't know how important they
are: I've recompiled a working kernel under &linapus;
without the patches. The patches are from a posting on the
&linppc; kernel list.</para>
</listitem>
</itemizedlist>
<emphasis>980525</emphasis>
<itemizedlist>
<listitem><para> More patches for vger and the &linm68k;
kernel have been submitted.</para>
</listitem>
<listitem><para> &linapus; is now up-to-date with &linm68k;
2.1.101 and &linppc;-vger-980523. </para>
</listitem>
<listitem><para> I finally got around to installing a new disk
in my &amiga; so I can now do some more testing on
it. Also installed &rhppc;/1998.</para>
</listitem>
<listitem><para> Egcs-1.0.3 has been released. There are still
some &linppc;-specific patches which have not been
included, but with egcs-1.0.3 and binutils-2.9.1 I can
compile a working kernel under &linapus;.</para>
</listitem>
</itemizedlist>
<emphasis>980521</emphasis>
<itemizedlist>
<listitem><para> Added a new section with mirror sites. First
entry is in Poland (thanks Bartek). If you have made a
mirror or an archive of the mailing list please let me
know.</para>
</listitem>
<listitem><para> Jimmy "What's-yer-sir-name?" reported that X
is finally running on CyberVision. Shortly after Jeffrey
W. Davis posted a nice HOWTO on the &linapus; kernel list
which I have put in the FAQ section.</para>
</listitem>
<listitem><para> Most of the remaining &linapus; patches have
been applied to the &cpuppc; tree at vger.</para>
</listitem>
</itemizedlist>
<emphasis>980516</emphasis>
<itemizedlist>
<listitem><para> I added a new section about kernel debugging.</para>
</listitem>
<listitem><para> I completed the &linm68k;-2.1.99 and
vger-980424 merge. I'll upload this diff and start working
on merging 2.1.1xx and vger-980514.</para>
</listitem>
<listitem><para> Sven Ottemann reports that CyberVision is
working with the console. X does <emphasis>not</emphasis>
work. (old news btw, but now it's in the list).</para>
</listitem>
</itemizedlist>
<emphasis>980514</emphasis>
<itemizedlist>
<listitem><para> Alex Kazik reports that 980507 change fixed
the problems with the GVP 11 SCSI driver.</para>
</listitem>
</itemizedlist>
<emphasis>980512</emphasis>
<itemizedlist>
<listitem><para> The 980507 change did solve the problem with
at least A3000 SCSI. The 53c7xx driver (A4000T+A4091) is
also broken under &linm68k; so it will not be fixed by the
change.</para>
</listitem>
<listitem><para> I got my vger merge booting as far as
INIT. I'll merge it with 2.1.99 before tracking the last
problems down.</para>
</listitem>
<listitem><para> Removed A4091 and A4000T SCSI drivers from
the precompiled kernel.</para>
</listitem>
</itemizedlist>
<emphasis>980507</emphasis>
<itemizedlist>
<listitem><para> Hopefully fixed kernel_map/VTOP
problems. Also cleaned up cache functions. SCSI users
should try if this improves things.</para>
</listitem>
</itemizedlist>
<emphasis>980506</emphasis>
<itemizedlist>
<listitem><para> Removed the sound driver from the precompiled
kernel.</para>
</listitem>
</itemizedlist>
<emphasis>980503</emphasis>
<itemizedlist>
<listitem><para> Completed vger merge. Can't test it though
since my shiny new &rh; 5.0 box doesn't like me using the
network. I'll re-install 4.2 sometime in the coming
week.</para>
</listitem>
<listitem><para> I think I have found the problem with the
SCSI drivers: they use cache_flush/clear with addresses
that are not necessarily in kernel space (bounce
buffers. user space buffers(?)). The &cpuppc; uses
<emphasis>virtual</emphasis> addresses in its cache
instructions and PTOV is non-trivial, slow and definitely
not working correctly at the moment. Have to give this
some serious thought.</para>
</listitem>
</itemizedlist>
<emphasis>980502</emphasis>
<itemizedlist>
<listitem><para> Thomas Lohmann reports that Ariadne is
working.</para>
</listitem>
<listitem><para> Updated texts about news group and
cross-compilation.</para>
</listitem>
</itemizedlist>
<emphasis>980501</emphasis>
<itemizedlist>
<listitem><para> Jouko Pynnonen reports that &linapus; is
finally working on the A1200 &blzppc;.</para>
</listitem>
<listitem><para> Sven Ottemann updated the
<command>hdinstall</command> script.</para>
</listitem>
<listitem><para> Holger Jakob uploaded an XF86Config example
file for 640x480x256 AGA, and a patch for gpm.</para>
</listitem>
</itemizedlist>
<emphasis>980429</emphasis>
<itemizedlist>
<listitem><para> Tripled SCSI timeouts. </para>
</listitem>
<listitem><para> Reverted BAT mapping change of
980425. Configurations with non-power-of-two memory sizes
fail with this.</para>
</listitem>
<listitem><para> I have to rewrite the memory mapping to
support the &cybppc; HW properly: the &cpuppc; is not
happy with the weird alignments caused by growing the
memory downwards (as designed by &p5;). If &ados; was
using the MMU, I'm sure the memory base would be at the
bottom of the addressing space.</para>
</listitem>
<listitem><para> Changed the CPU speeds for &blzppc; to
50MHz/66MHz.</para>
</listitem>
<listitem><para> Continue with vger merging.</para>
</listitem>
</itemizedlist>
<emphasis>980428</emphasis>
<itemizedlist>
<listitem><para> Started to merge the latest vger changes into
the &linapus; kernel sources.</para>
</listitem>
</itemizedlist>
<emphasis>980427</emphasis>
<itemizedlist>
<listitem><para> Use same page fault mechanism on &cpu603; as
on &cpu604;. May solve problem with &blzppc;.</para>
</listitem>
<listitem><para> Realized that some people might have a memory
configuration which cannot be mapped with BATs. Added
instructions in <xref linkend="booting">.</para>
</listitem>
<listitem><para> The kernel I build with egcs-1.0.2 after
disabling the inline assembly versions of __swab16/32
seems pretty stable.</para>
</listitem>
</itemizedlist>
<emphasis>980426</emphasis>
<itemizedlist>
<listitem><para> Made a small (fancy :) script which makes it
easy to mark changes in the HTML version of this document
with colors.</para>
</listitem>
<listitem><para> Had a go at using egcs to compile the
kernel. Didn't work very well. I hope the next egcs
release will fix it. If you have the time, please try to
get gcc-2.7.2.1 (available from &sunsite; in misc) running
under &linapus; and upload the binaries to
&sunsite;.</para>
</listitem>
<listitem><para> Sven Ottemann reports that the floppy driver
works with both affs and msdos formatted floppies. </para>
</listitem>
</itemizedlist>
<emphasis>980425</emphasis>
<itemizedlist>
<listitem><para> Map exception vectors and &cybppc; control
vectors with different BATs for improved
performance.</para>
</listitem>
<listitem><para> Unfortunately the last booter changes made it
unusable. The 980425 version should be better.</para>
</listitem>
</itemizedlist>
<emphasis>980424</emphasis>
<itemizedlist>
<listitem><para> Thomas Haller reports that A3000 SCSI
actually works if DMA is disabled.</para>
</listitem>
<listitem><para> Added some progress information to the booter
which can be used (hopefully) to find the &blzppc;
problems. See FAQ.</para>
</listitem>
</itemizedlist>
<emphasis>980423</emphasis>
<itemizedlist>
<listitem><para> Fiddled a bit with gcc under &linapus;. The
version of gcc I use on Concubine (x86) I cannot get
properly working under &linapus;. I have to look into the
problems with egcs RSN. I put an additional gcc patch on
&sunsite;/misc, but it's probably not worth getting;
&linppc; is going to use egcs in the future so I have to
get those problems fixed anyways. Stay tuned!</para>
</listitem>
</itemizedlist>
<emphasis>980422</emphasis>
<itemizedlist>
<listitem><para> Fixed bus_to_virt/virt_to_bus macros. May
help A4000T and A4091 drivers.</para>
</listitem>
</itemizedlist>
<emphasis>980421</emphasis>
<itemizedlist>
<listitem><para> Checked if LPSTOP could be used on the
&cpu060; to reduce heat in the box. It cannot.</para>
</listitem>
<listitem><para> Fixed problem with debug=mem. This may also
affect drivers using the VTOP macro.</para>
</listitem>
</itemizedlist>
<emphasis>980420</emphasis>
<itemizedlist>
<listitem><para> Completed the last part of the FAQ. Added the
new kernel mailing list address.</para>
</listitem>
</itemizedlist>
<emphasis>980419</emphasis>
<itemizedlist>
<listitem><para> Proper bus speed check for A1200 &blzppc;.</para>
</listitem>
<listitem><para> The new HTML FAQ almost done. Will announce
it and the new directory Monday.</para>
</listitem>
</itemizedlist>
<emphasis>980418</emphasis>
<itemizedlist>
<listitem><para> Added patch from Holger Jakob to allow
inclusion of DMA sound.</para>
</listitem>
</itemizedlist>
<emphasis>980417</emphasis>
<itemizedlist>
<listitem><para> Started work on SGML'ogrifing the FAQ.</para>
</listitem>
<listitem><para> Got a dedicated directory at
&sunsite;. Thanks Karsten!</para>
</listitem>
</itemizedlist>
<emphasis>980416</emphasis>
<itemizedlist>
<listitem><para> Added a patch from Carsten Pluntke to fix a
virtual-to-physical address translation problem causing X
to crash.</para>
</listitem>
<listitem><para> Fixed a potential problem with
ioremap. Hopefully SCSI drivers using kernel_map
(A4000T/A4091/Fastlane) will now work.</para>
</listitem>
</itemizedlist>
<emphasis>980414</emphasis>
<itemizedlist>
<listitem><para> Added a &gdb; debugging stub to the kernel
sources (not the binaries).</para>
</listitem>
<listitem><para> Sven Ottemann completed the HD install
script. Get <filename>hdinstall.lha</filename> and the
newest FAQ for instructions.</para>
</listitem>
<listitem><para> Added handling for booting on systems where
the ROM has been mapped to RAM. (not tested)</para>
</listitem>
<listitem><para> Added a compiled version of the kernel
without the A3000 SCSI driver.</para>
</listitem>
<listitem><para> Added PPP driver.</para>
</listitem>
</itemizedlist>
<emphasis>980409</emphasis>
<itemizedlist>
<listitem><para> Added a few extra drivers.</para>
</listitem>
</itemizedlist>
<emphasis>980331</emphasis>
<itemizedlist>
<listitem><para> Applied some more of Roman's patches.</para>
</listitem>
<listitem><para> Fixed RAM disk problem.</para>
</listitem>
</itemizedlist>
<emphasis>980326</emphasis>
<itemizedlist>
<listitem><para> Applied a few of Roman's patches.</para>
</listitem>
<listitem><para> Changed the way the exception vectors are
handled. You have to get the new &boothack; as well
(bh980326.lha).</para>
</listitem>
</itemizedlist>
<emphasis>980324</emphasis>
<itemizedlist>
<listitem><para> Moved the patches to 2.1.90. </para>
</listitem>
<listitem><para> I still have a few of Roman Zippel's patches
that have not been applied.</para>
</listitem>
</itemizedlist>
<emphasis>980316</emphasis>
<itemizedlist>
<listitem><para> I wrote a small &linapus; FAQ available from
&sunsite; in the apus directory.</para>
</listitem>
</itemizedlist>
<emphasis>980224</emphasis>
<itemizedlist>
<listitem><para> The kernel now auto detects the bus speed.</para>
</listitem>
<listitem><para> If you have a system with a 60MHz bus speed
and press the left mouse button while booting, the memory
waitstate will be removed (this requires 60ns RAM).</para>
</listitem>
</itemizedlist>
<emphasis>980223</emphasis>
<itemizedlist>
<listitem><para> Kernels now compiled for 60MHz and 66MHz
busses.</para>
</listitem>
<listitem><para> Includes a few more drivers.</para>
</listitem>
</itemizedlist>
<emphasis>980216</emphasis>
<itemizedlist>
<listitem><para> Kernel seems to be working. I experienced
some random signals to user processes during the weekend,
but was not able to reproduce it. </para>
</listitem>
<listitem><para> Compiled a version for 50MHz busses with 60ns
RAM.</para>
</listitem>
<listitem><para> Included System.map and .config for
reference.</para>
</listitem>
</itemizedlist>
<emphasis>980212</emphasis>
<itemizedlist>
<listitem><para> Did some more magic with the interrupt
handling.</para>
</listitem>
<listitem><para> Tracked down the problem causing the kernel
to hang from time to time (A2065).</para>
</listitem>
<listitem><para> Compiled two versions of the kernel; one for
50MHz bus and one for 66MHz bus. I will add auto detect
soon.</para>
</listitem>
</itemizedlist>
<emphasis>980208</emphasis>
<itemizedlist>
<listitem><para>Moved my changes to 2.1.85. </para>
</listitem>
<listitem><para>Cleaned up the handling of
interrupts. Mismatch between &p5; doc and actual behavior
(&p5; notified).</para>
</listitem>
<listitem><para>The kernel still hangs from time to time
(while processing bottom half interrupt handlers). This
might be due to some spurious interrupts, improper
interrupt handling, or some problem in the kernel code
that only affects &linapus;. I'm looking into it.</para>
</listitem>
</itemizedlist>
<emphasis>980205</emphasis>
<itemizedlist>
<listitem><para> Added minix support to the kernel. </para>
</listitem>
<listitem><para> The kernel happily boots the ram disk but is
pretty unstable. This is due to improper interrupt
handling. I think I have it nailed down, though.</para>
</listitem>
</itemizedlist>
<emphasis>980204</emphasis>
<itemizedlist>
<listitem><para> Ram disks now work properly (also updated the
booter).</para>
</listitem>
</itemizedlist>
<emphasis>980203</emphasis>
<itemizedlist>
<listitem><para> The patched instructions in the hashing
algorithm had to be copied to 0xfff00000 where the
exception vectors are located on &linapus;.</para>
</listitem>
</itemizedlist>
<emphasis>980202</emphasis>
<itemizedlist>
<listitem><para> IDE driver is now working. </para>
</listitem>
<listitem><para> Kernel hangs when elf_create_table is
accessing the stack of the user program to be launched
(problem with exception handlers?)</para>
</listitem>
</itemizedlist>
</para>
</chapter>
<chapter id="people"><title>People</title>
<para>Here is a list of the people who helped make &linapus; what
it is today. There is also room for <emphasis>your</emphasis>
name!</para>
<sect1><title>&p5; Appointed Developers</title>
<para>&p5; supported the port of &linux; to their &cybppc;
hardware by disclosing information about the hardware
to:</para>
<itemizedlist>
<listitem><para>Roman Zippel (<ulink
url="mailto:zippel@fh-brandenburg.de">
zippel@fh-brandenburg.de</ulink>)</para>
</listitem>
<listitem><para>Jes Sørensen (<ulink
url="mailto:Jes.Sorensen@cern.ch">
Jes.Sorensen@cern.ch</ulink>)</para>
</listitem>
<listitem><para>Jesper Skov (<ulink url="mailto:jskov@cygnus.co.uk">
jskov@cygnus.co.uk</ulink>)</para>
</listitem>
</itemizedlist>
</sect1>
<sect1><title>Contributors</title>
<para>A few people have started helping with &linapus;. I hope
more will join (see <xref linkend="todo">). If you were not
critically deprived of air at birth, and thus do not see the
fun in kernel hacking, you can still help. Complement or add
sections to &thisdoc;, get responsibility for &debian; or
&rh; packages of tools you like, write a helping text for
others about a problem you have fought your way through, be
helpful on the news group (this would be very appreciated - I
can only read news at work and don't always have the time to
be helpful myself), send me (or others) grateful emails, or
even tons of money. Use your imagination and help make
&linm68k; and &linapus; better systems for people with less
experience than yourself.</para>
<para>There are two parties in particular that I feel deserve
kudos: &p5; for helping this port along, and the system
administrators at &sunsite; (Karsten Thygesen in particular)
for supplying disk space and generally for being a nice bunch
(as all Danes are, of course :).</para>
<para>For paragraph-sized contributions to &thisdoc;, I put the
author's name above the text. Patches to the kernel are
rewarded with gratitude and (for bigger stuff) a short mention
below. I don't think I want to spend time keeping this part of
the document up to date though, so I won't be mentioning every
little change. What I will do is to include your name when
describing changes in <xref linkend="history"> and
make a big'ol' list below with email addresses of contributors
(big'n'small).</para>
<para>If you feel I have forgotten you, remind me by sending an
email (and tons of money).</para>
<itemizedlist>
<listitem><para> Gerard Cornu(<ulink
url="mailto:gcornu@dtr.fr">
gcornu@dtr.fr</ulink>)</para>
</listitem>
<listitem><para> (<ulink
url="mailto:kcci1@central.susx.ac.uk">
kcci1@central.susx.ac.uk</ulink>)</para>
</listitem>
<listitem><para>Jeffrey W. Davis (<ulink
url="mailto:doctorj@netusa1.net">
doctorj@netusa1.net</ulink>)</para>
</listitem>
<listitem><para>Christophe Decanini (<ulink
url="mailto:cdecanini@yahoo.com">
cdecanini@yahoo.com</ulink>)</para>
</listitem>
<listitem><para>Marco De Vitis (<ulink
url="mailto:marco.dvv@flashnet.it">
marco.dvv@flashnet.it</ulink>)</para>
</listitem>
<listitem><para>Michel Dänzer (<ulink
url="mailto:michdaen@iiic.ethz.ch">
michdaen@iiic.ethz.ch</ulink>)</para>
</listitem>
<listitem><para>Massimo Gais (<ulink
url="mailto:ftpadmin@ftp.unina.it">
ftpadmin@ftp.unina.it</ulink>)</para>
</listitem>
<listitem><para>Matthias Goerdeler (<ulink
url="mailto:goerdler@hp1.imm.rwth-aachen.de">
goerdler@hp1.imm.rwth-aachen.de</ulink>)</para>
</listitem>
<listitem><para>Arno Griffioen (<ulink
url="mailto:arno@usn.nl"> arno@usn.nl</ulink>)</para>
</listitem>
<listitem><para>Sinan Gurkan (<ulink
url="mailto:sgurkan@artemis.efes.net">
sgurkan@artemis.efes.net</ulink>)</para>
</listitem>
<listitem><para>Thomas Haller (<ulink
url="mailto:Thomas-h8t.Haller@ubs.ch">
Thomas-h8t.Haller@ubs.ch</ulink>)</para>
</listitem>
<listitem><para>Holger Jakob (<ulink
url="mailto:jakob@ph-cip.Uni-Koeln.DE">
jakob@ph-cip.Uni-Koeln.DE</ulink>)</para>
</listitem>
<listitem><para>Jens Kristian Jensen (<ulink
url="mailto:judas@cs.auc.dk">
judas@cs.auc.dk</ulink>)</para>
</listitem>
<listitem><para>Jimmy (<ulink
url="mailto:Jimmy@Stud-Mailer.Uni-Marburg.DE">
Jimmy@Stud-Mailer.Uni-Marburg.DE</ulink>)</para>
</listitem>
<listitem><para>Alex Kazik (<ulink
url="mailto:martin.koenig@gmx.net">
martin.koenig@gmx.net</ulink>)</para>
</listitem>
<listitem><para> Martin Koenig(<ulink url="mailto:alx@gmx.de">
alx@gmx.de</ulink>)</para>
</listitem>
<listitem><para>Bartek Kozakiewicz (<ulink
url="mailto:coza@snickers.ek.univ.gda.pl">
coza@snickers.ek.univ.gda.pl</ulink>)</para>
</listitem>
<listitem><para>Chris Lawrence (<ulink
url="mailto:quango@watervalley.net">
quango@watervalley.net</ulink>)</para>
</listitem>
<listitem><para>Thomas Lohmann (<ulink
url="mailto:tlohmann@scobs.de">
tlohmann@scobs.de</ulink>)</para>
</listitem>
<listitem><para>Sven Luther (<ulink
url="mailto:luther@dpt-info.u-strasbg.fr">
luther@dpt-info.u-strasbg.fr</ulink>) SCSI support for
Blizzard controllers.</para>
</listitem>
<listitem><para>Peter McGavin (<ulink
url="mailto:P.McGavin@irl.cri.nz">
P.McGavin@irl.cri.nz</ulink>)</para>
</listitem>
<listitem><para>Carlos Mayo (<ulink
url="mailto:COMPMAY@teleline.es">
COMPMAY@teleline.es</ulink>)</para>
</listitem>
<listitem><para>Ilario Nardinocchi (<ulink
url="mailto:nardicon@cs.unibo.it">
nardicon@cs.unibo.it</ulink>) CVPPC driver.</para>
</listitem>
<listitem><para>Sven Ottemann (<ulink
url="mailto:Sven.Ottemann@Student.Uni-Magdeburg.DE">
Sven.Ottemann@Student.Uni-Magdeburg.DE</ulink>) Hard
disk install script for the &rh; base system.</para>
</listitem>
<listitem><para>Frank Petzold (<ulink
url="mailto:fpetzold@hepe.com">
fpetzold@hepe.com</ulink>)</para>
</listitem>
<listitem><para>Carsten Pluntke (<ulink
url="mailto:su0289@sx2.hrz.uni-dortmund.de">
su0289@sx2.hrz.uni-dortmund.de</ulink>) Fixed vm problem
with X.</para>
</listitem>
<listitem><para>Jouko Pynnonen (<ulink
url="mailto:pynjo@jytol.fi">
pynjo@jytol.fi</ulink>)</para>
</listitem>
<listitem><para>Robert Ramiega (<ulink
url="mailto:robert@plukwa.pdi.net">
robert@plukwa.pdi.net</ulink>)</para>
</listitem>
<listitem><para>Francisco Sepulveda (<ulink
url="mailto:Francisco.Sepulveda@ico.unil.ch">
Francisco.Sepulveda@ico.unil.ch</ulink>)</para>
</listitem>
<listitem><para>Christian T. Steigies (<ulink
url="mailto:steigies@physik.uni-kiel.de">
steigies@physik.uni-kiel.de</ulink>)</para>
</listitem>
<listitem><para>Ken (& Julian) Tyler (<ulink
url="mailto:kent@werple.net.au">
kent@werple.net.au</ulink>) Fixed the &rhinstaller;
scripts to work with &linapus;.</para>
</listitem>
<listitem><para>Geert Uytterhoeven (<ulink
url="mailto:Geert.Uytterhoeven@cs.kuleuven.ac.be">
Geert.Uytterhoeven@cs.kuleuven.ac.be</ulink>) X server
binaries. &rhppc; base system archive and installation
help. Santa's little vger helper :)</para>
</listitem>
</itemizedlist>
</sect1>
<sect1><title>Contributing</title>
<para>If you have any contributions to &linapus; (code, ideas,
changes to &thisdoc;, whatever) please send them to the
&linapus; kernel mailing list. Archives and/or packages can be
uploaded to <xref linkend="sd-incoming"> <emphasis>(remember
to notify me via mail)</emphasis>.</para>
</sect1>
</chapter>
<chapter id="links"><title>Links</title>
<para> If you have an idea for additional
(&linapus; relevant) links, please let me know.</para>
<sect1 id="links-linux"><title>&linux; Links</title>
<informaltable frame="all">
<tgroup cols="3">
<tbody>
<row>
<entry align="center"><emphasis>&linapus;</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>FTP Location</emphasis>
</entry>
</row>
<row>
<entry>&linapus; Master Site
</entry>
<entry><ulink
url="http://sunsite.auc.dk:/local/os/linux/apus">
sunsite.auc.dk:/local/os/linux/apus</ulink>
</entry>
<entry><ulink
url="ftp://sunsite.auc.dk:/local/os/linux/apus">
sunsite.auc.dk:/local/os/linux/apus</ulink>
</entry>
</row>
<row>
<entry>&linapus; Poland Mirror
</entry>
<entry>
</entry>
<entry><ulink
url="ftp://snickers.ek.univ.gda.pl/pub/apus">
snickers.ek.univ.gda.pl/pub/apus</ulink>
</entry>
</row>
<row>
<entry>&linapus; Italian Mirror
</entry>
<entry>
</entry>
<entry><ulink
url="ftp://ftp.unina.it">
ftp.unina.it</ulink>
</entry>
</row>
<row>
<entry align="center"><emphasis>&linm68k;</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>FTP Location</emphasis>
</entry>
</row>
<row>
<entry>&linm68k; Kernel Master Site
</entry>
<entry><ulink
url="http://sunsite.auc.dk:/local/os/linux/680x0">
sunsite.auc.dk:/local/os/linux/680x0</ulink>
</entry>
<entry><ulink
url="ftp://sunsite.auc.dk:/local/os/linux/680x0">
sunsite.auc.dk:/local/os/linux/680x0</ulink>
</entry>
</row>
<row>
<entry>&linm68k; Home Page
</entry>
<entry><ulink
url="http://www.linux-m68k.org">
www.linux-m68k.org</ulink>
</entry>
<entry>
</entry>
</row>
<row>
<entry>Permedia2 (CyberVision/PPC) Frame Buffer Home Page
</entry>
<entry><ulink
url="http://www.cs.unibo.it/~nardinoc/pm2fb/">
http://www.cs.unibo.it/~nardinoc/pm2fb/</ulink>
</entry>
<entry>
</entry>
</row>
<row>
<entry align="center"><emphasis>&linppc;</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>FTP Location</emphasis>
</entry>
</row>
<row>
<entry>&linppc; Master Site
</entry>
<entry><ulink
url="http://www.linuxppc.org">
www.linuxppc.org</ulink>
</entry>
<entry><ulink
url="ftp://ftp.linuxppc.org">
ftp.linuxppc.org</ulink>
</entry>
</row>
<row>
<entry align="center"><emphasis>&debppc;</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>FTP Location</emphasis>
</entry>
</row>
<row>
<entry>The &debppc; port
</entry>
<entry><ulink
url="http://www.debian.org/ports/powerpc/">
www.debian.org/ports/powerpc/</ulink>
</entry>
<entry>
</entry>
</row>
<row>
<entry>&debppc; packages
</entry>
<entry>
</entry>
<entry><ulink
url="ftp://ftp.debian.org/debian/dist/main/binary-powerpc/">
ftp.debian.org/debian/dist/main/binary-powerpc/</ulink>
</entry>
</row>
<row>
<entry>&debppc; install stuff
</entry>
<entry>
</entry>
<entry><ulink
url="ftp://ftp.debian.org/debian/dists/sid/main/disks-powerpc/2.0.11.4_1998-10-15/">
ftp.debian.org/debian/dists/sid/main/disks-powerpc/2.0.11.4_1998-10-15/</ulink>
</entry>
</row>
<row>
<entry align="center"><emphasis>&linux; Help</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>Comment</emphasis>
</entry>
</row>
<row>
<entry>News Archive
</entry>
<entry><ulink
url="http://www.dejanews.com">
www.dejanews.com</ulink>
</entry>
<entry>Search for keywords, include "linux"
</entry>
</row>
<row>
<entry>WEB Search
</entry>
<entry><ulink
url="http://www.altavista.com">
www.altavista.com</ulink>
</entry>
<entry>Search for keywords, include "linux"
</entry>
</row>
<row>
<entry>MiningCo
</entry>
<entry><ulink
url="http://linux.miningco.com">
linux.miningco.com</ulink>
</entry>
<entry>Search for keywords
</entry>
</row>
<row>
<entry align="center"><emphasis>&linux; Kernel Hacking
</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>Comment</emphasis>
</entry>
</row>
<row>
<entry>&linux; Kernel (Hacking) FAQ
</entry>
<entry><ulink
url="http://www.tux.org/lkml/">
www.tux.org/lkml/</ulink>
</entry>
<entry>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<sect2><title>Software Packages</title>
<informaltable frame="all">
<tgroup cols="3">
<tbody>
<row>
<entry align="center"><emphasis>Software</emphasis>
</entry>
<entry align="center"><emphasis>HTTP Location</emphasis>
</entry>
<entry align="center"><emphasis>FTP Location</emphasis>
</entry>
</row>
<row>
<entry>binutils
</entry>
<entry>
</entry>
<entry><ulink
url="ftp://prep.ai.mit.edu">prep.ai.mit.edu</ulink>,
<ulink
url="ftp://sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/">
sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/</ulink>
</entry>
</row>
<row>
<entry>egcs
</entry>
<entry><ulink
url="http://egcs.cygnus.com">egcs.cygnus.com</ulink>
</entry>
<entry><ulink
url="ftp://egcs.cygnus.com">egcs.cygnus.com</ulink>,
<ulink
url="ftp://sunsite.auc.dk/mirrors/egcs.cygnus.com">
sunsite.auc.dk/mirrors/egcs.cygnus.com</ulink>
</entry>
</row>
<row>
<entry>Mozilla
</entry>
<entry><ulink
url="http://www.mozilla.org">www.mozilla.org</ulink>
</entry>
<entry><ulink
url="ftp://ftp.mozilla.org">ftp.mozilla.org</ulink>
</entry>
</row>
<row>
<entry>&rhppc;
</entry>
<entry><ulink
url="http://www.linuxppc.org">
www.linuxppc.org</ulink>
</entry>
<entry><ulink
url="ftp://ftp.linuxppc.org">
ftp.linuxppc.org</ulink>
</entry>
</row>
<row>
<entry>X
</entry>
<entry><ulink
url="http://www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz">
www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz</ulink>
</entry>
<entry>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2><title>Related &cybppc; and &ados; Sites</title>
<para>&p5; <ulink
url="http://www.phase5.de">www.phase5.de</ulink>.</para>
</sect2>
</sect1>
</chapter>
<chapter id="sunsite"><title>&sunsite;</title>
<para><ulink url="http://sunsite.auc.dk">&sunsite;</ulink> is the
main distribution site for both the &linm68k; and &linapus;
kernels (no, it's not a coincidence: both Jes and I studied at
Aalborg University). There's lots of other good stuff there, and
it's well worth a visit. You can access it by both HTTP and FTP
(using the same hostname and paths).</para>
<para>You can find &linm68k; related stuff (including the
&linm68k; FAQ) in the directory <ulink
url="http://sunsite.auc.dk/local/os/linux/680x0/">
sunsite.auc.dk/local/os/linux/680x0/</ulink>.</para>
<para>The &linapus; directory is <ulink
url="http://sunsite.auc.dk/local/os/linux/apus/">
sunsite.auc.dk/local/os/linux/apus/</ulink>. This directory
contains the following (and possibly more; have a look
around):</para>
<itemizedlist>
<listitem id="sd-deb" xreflabel="the 'DEB-APUS' directory at
&sunsite;">
<para>DEB-APUS</para>
<para> Directory with &debian; packages recompiled especially
for &linapus;. I need <emphasis>your</emphasis> help to get
it filled with good stuff!</para>
</listitem>
<listitem id="sd-rpm" xreflabel="the 'RPM-APUS' directory at
&sunsite;">
<para>RPM-APUS</para>
<para> Directory with &rh; packages recompiled especially
for &linapus;. I need <emphasis>your</emphasis> help to get
it filled with good stuff!</para>
</listitem>
<listitem id="sd-boothack" xreflabel="the 'boothack' directory at
&sunsite;">
<para>boothack</para>
<para> Directory with the special version of &amiboot;
required to boot a &linapus; kernel.</para>
</listitem>
<listitem id="sd-contrib" xreflabel="the 'contrib' directory at
&sunsite;">
<para>contrib</para>
<para> Directory where I put kernel images and diffs
contributed by users. If you want to contribute, upload to
incoming and notify me via mail
<footnote id="ft-readme"><para>I only accept uploads with an
accompanying <filename>.readme</filename> file
containing:</para>
<itemizedlist>
<listitem><para><emphasis>Uploader:</emphasis> Name and
email address.</para>
</listitem>
<listitem><para><emphasis>Contents:</emphasis> Archive
description and/or a description of why people
should use it.</para>
</listitem>
</itemizedlist>
<para>Also, please make sure to notify me when an archive
becomes obsolete so it can be deleted.</para>
</footnote>.</para>
</listitem>
<listitem id="sd-docs" xreflabel="the 'docs' directory at &sunsite;">
<para>docs</para>
<para> Directory with &thisdoc; in HTML and SGML
formats. The file <filename>faq-all.tgz</filename>
contains all the files for easy downloading.</para>
</listitem>
<listitem id="sd-incoming" xreflabel="the 'incoming' directory
at &sunsite;">
<para>incoming</para>
<para> Directory where you can upload contributions
<footnoteref linkend="ft-readme">.</para>
</listitem>
<listitem id="sd-install" xreflabel="the 'install'
directory at &sunsite;">
<para>install</para>
<para> Directory with installation related files and
directories..</para>
</listitem>
<listitem id="sd-install-rh" xreflabel="the &rh; 'install'
directory at &sunsite;">
<para>install/redhat</para>
<para> Directory with files required to create a &rhppc; or
&rhrc; system.</para>
</listitem>
<listitem id="sd-install-deb" xreflabel="the &debian; 'install'
directory at &sunsite;">
<para>install/debian</para>
<para> Directory with files required to create a &debian;
system.</para>
</listitem>
<listitem id="sd-kernels" xreflabel="the 'kernels' directory at
&sunsite;">
<para>kernels</para><para> Directory with kernel binaries
and diffs.</para>
</listitem>
<listitem id="sd-latest" xreflabel="the 'latest' directory at
&sunsite;">
<para>latest</para><para> Directory with links to the newest
kernel binary and booter.</para>
</listitem>
<listitem id="sd-misc" xreflabel="the 'misc' directory at &sunsite;">
<para>misc</para>
<para> Directory with miscellaneous tidbits, such as the build
tools I'm using to make the precompiled kernel images.</para>
</listitem>
</itemizedlist>
<para>The &linapus; kernel mailing list is also hosted by
&sunsite;. Send for help at <ulink
url="mailto:linux-apus-help@sunsite.auc.dk">
linux-apus-help@sunsite.auc.dk</ulink>. The list is also
available via NTTP from <ulink
url="news://sunsite.auc.dk">sunsite.auc.dk</ulink> (look for
sunsite.linux.apus). Please read <xref linkend="etiquette">
before posting to this list.</para>
<sect1><title>&linapus; Mirror Sites</title>
<para>The <filename class=directory>apus</filename> directory at
&sunsite; is mirrored a few places thanks to the people
mentioned in parenthesis:</para>
<para>Poland (FTP): <ulink
url="ftp://snickers.ek.univ.gda.pl/pub/apus">
snickers.ek.univ.gda.pl/pub/apus</ulink> (Bartek
Kozakiewicz)</para>
<para>Italy (FTP): <ulink url="ftp://ftp.unina.it">
ftp.unina.it</ulink> (Massimo Gais)</para>
<!--
<para>The mailing list is also archived at other sites than
&sunsite; thanks to the people mentioned in parenthesis:
</para>
-->
<para>If you have the space (and time?) to make a mirror of
either the <filename class=directory>apus</filename> directory
at &sunsite; or make an archive of the &linapus; kernel
mailing list, please let me know. &sunsite; is close and
convenient to use for me, but that may not be so for
others.</para>
</sect1>
</chapter>
</part>
<part><title>Developer Information</title>
<partintro>
<para> Hi guys. Here are all the developer specific
chapters. I'll get it cleaned up eventually. Your job to write
new sections/chapters if you see the need (or at least let me
know of any text you think could be helpful). Well, you know
the drill...</para>
</partintro>
<chapter><title>Getting The Kernel</title>
<sect1><title>The Kernel Diffs</title>
<para> This section describes how you can recompile
your own kernel. It may be necessary to do if the prebuilt
kernels do not contain drivers for some of your
equipment. Rebuilding the kernel including only drivers for
the equipment you have may also result in slightly more memory
available for applications.</para>
<para> The diff files found at &sunsite; are relative to the
last release of the &linm68k; developer sources. The diffs are
named <filename>linux-2.1.115-m68k-YYMMDD.diff.gz</filename>
(2.1.115 is the current &linm68k; version at the time of
writing - you may find patches for more recent
kernels). </para>
<para> Always apply my patches to a clean set of &linm68k;
sources as found on &sunsite; to avoid getting rejects. My
diffs may include (parts) of patches posted to the &linm68k;
kernel list.</para>
<para> I have also started uploading &linapus;
relative diffs. These are named
<filename>linux-apus-YYMMDD.diff.gz</filename> and are
relative to the previous &linapus; release.</para>
<sect2 id="recompile"><title>Recompiling Your Own Kernel</title>
<para> Both because the precompiled kernels are so big, and
because the set of included drivers may change without
notice, you should recompile your own customized kernel when
you have used a precompiled kernel to install your system.</para>
<para>If you want to help (actively) with the development of
&linm68k; and/or &linapus; you also need to recompile your own
kernel (yes, <emphasis>you</emphasis> can hack the
kernel. All that is really required is build tools,
patience, a bit of interest in the subject and possibly some
C knowledge (I learned C by hacking &linux; -- see the two
previous requirements :))</para>
<para>It is possible to get a reasonable stable kernel by
following the advice below. Many people who have problems
with the kernels they build themselves usually didn't follow
the below advice. In particular, use the specified tool
versions even if newer are available. And build the tools
yourself since prebuilt tools may include patches that could
foul things up.</para>
<para> You can find binutils at <ulink
url="ftp://prep.ai.mit.edu">prep.ai.mit.edu</ulink> or one
of its mirrors (e.g., <ulink
url="ftp://sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/">
sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/</ulink>). You
can find egcs at <ulink
url="ftp://egcs.cygnus.com">egcs.cygnus.com</ulink> or one
of its mirrors (e.g., <ulink
url="ftp://sunsite.auc.dk/mirrors/egcs.cygnus.com">
sunsite.auc.dk/mirrors/egcs.cygnus.com</ulink>).</para>
<para> Still, since it is a developer kernel, your mileage may
vary, even if you painstakingly follow the below.</para>
<para> <emphasis>Note: There has been reported
problems with rebuilding egcs-1.1 from the source code
archive; it requires a C++ compiler, even if you
specify LANGUAGES to only include C. Workaround is to
build everything (i.e., don't use the LANGUAGES
option).</emphasis></para>
<sect3><title>Basic Kernel Compilation</title>
<para> A good way to start compiling your own
kernel is by using the configuration I use to build
kernels. That way, you can be sure that the kernel will
build without problems, and you can test that it works
just as well as the ones I have built.</para>
<para> First patch the kernel:</para>
<screen>
tar xzf linux-2.1.115.tar.gz
cd linux-2.1.115
patch -d. -p0 < .../linux-2.1.115-m68k-980814.diff</screen>
<para> Then copy the
<filename>.config</filename> from one of the archives
with precompiled kernels to the kernel directory,
configure and build the kernel:</para>
<screen>
cp [path of prebuilt kernel]/.config .
make oldconfig
make dep
make </screen>
<para> Now test the kernel. If it works,
reconfigure to suit your system and rebuild. Resolve
problems as they appear and send patches to the list
:)</para>
</sect3>
<sect3><title>Native Compilation</title>
<para>If you know how to recompile &linm68k; there shouldn't be
much of a difference - except that it will be done faster
:)</para>
<orderedlist>
<listitem><para> Get binutils-2.9.1 and egcs-1.1.</para>
</listitem>
<listitem><para> Configure, build and install
binutils.</para>
<screen>
tar xzf binutils-2.9.1.tar.gz
cd binutils-2.9.1
./configure
make
make install
cd .. </screen>
</listitem>
<listitem><para>Configure, build and install
egcs.</para>
<screen>
tar xzf egcs-1.1.tar.gz
cd egcs-1.1
mkdir build
cd build
../configure
make LANGUAGES=c
make LANGUAGES=c install </screen>
</listitem>
<listitem><para> Get the latest &linm68k; kernel sources
(2.1.115 as of the time of writing) and apply the
&linapus; patch.</para>
<screen>
tar xzf linux-2.1.115.tar.gz
cd linux-2.1.115
patch -d. -p0 < .../linux-2.1.115-m68k-980814.diff</screen>
</listitem>
<listitem><para> Configure and compile the kernel.</para>
<screen>
make config [select the options you want]
make dep
make </screen>
</listitem>
<listitem><para> Boot your shiny new kernel (see <xref
linkend="booting">).</para>
</listitem>
</orderedlist>
</sect3>
<sect3><title>Cross-Compilation</title>
<para> This is probably what you want to do if you want to
do some serious &linapus; development as it cuts down the
time of the build-boot-test cycle dramatically. You need a
slave box (like my PC 'Concubine') on which you do the
editing and building and a proper connection to the &amiga;
(I used serial for some months, but can warmly recommend
an Ethernet card).</para>
<para>Using a different build machine also allows you to get
serial output from the kernel you are testing and/or use a
remote debugger (beats
<function>printk</function>-debugging, I'm sure) if you
connect the machines with a null-modem cable.</para>
<para>You need a cross compilation environment, targeting
big-endian &cpuppc; ELF files. Here's how to build the required
binutils and compiler on another &linux; box:</para>
<orderedlist>
<listitem><para>Get binutils-2.9.1 and egcs-1.1.</para>
</listitem>
<listitem><para>Configure, build and install binutils for
target </para>
<screen>
tar xzf binutils-2.9.1.tar.gz
cd binutils-2.9.1
mkdir build
cd build
../configure --target=powerpc-unknown-linux
make
make install </screen>
<para> You should now have binutils targeted for &cpuppc;
installed in <filename class=directory>
/usr/local/powerpc-unknown-linux</filename>.</para>
</listitem>
<listitem><para>Get the files from <filename
class=directory> /usr/include</filename> of your
&linapus; box and put them in the <filename
class=directory>
/usr/local/powerpc-unknown-linux/include</filename>
directory of your build machine. (The files are
also available from <xref linkend="sd-misc">.)
Make sure that the
<filename>asm</filename> and
<filename>linux</filename> links point to the
location of those directories in the linux source
code you are trying to compile.</para>
</listitem>
<listitem><para>Configure egcs for
cross-compilation.</para>
<screen>
tar xzf egcs-1.1.tar.gz
cd egcs-1.1
mkdir build
cd build
../gcc/configure --target=powerpc-unknown-linux
make LANGUAGES=c
make LANGUAGES=c install </screen>
<para> You should now have gcc targeted for &cpuppc;
installed in <filename>
/usr/local/bin/powerpc-unknown-linux-gcc</filename>.</para>
</listitem>
<listitem><para>Configure and build the kernel.</para>
<screen>
make config [select the options you want]
make dep
make </screen>
<para>Notice that the kernel will be build using the
cross-compiler,
<filename>powerpc-unknown-linux-gcc</filename> which
automatically uses the correct &cpuppc;
binutils.</para>
</listitem>
<listitem><para>Copy the kernel to your &amiga;.</para>
</listitem>
<listitem><para>Boot your shiny new (cross-compiled)
kernel (see <xref linkend="booting">).</para>
</listitem>
</orderedlist>
<para>There's a cross-compiling mini HOWTO at <ulink
url="ftp://ftp.uni-erlangen.de:/pub/Linux/680x0/docs/cross-compiling-Mini-HOWTO">
ftp://ftp.uni-erlangen.de:/pub/Linux/680x0/docs/cross-compiling-Mini-HOWTO</ulink>
you can consult if you need more help.</para>
</sect3>
</sect2>
</sect1>
</chapter>
<chapter><title>Installing (Obsolete)</title>
<sect1><title>Really... Go away!</title>
<para> The obsolete ways of installing. Keeping it
in the developer part for a few more months</para>
<para>And depending on which installation method you choose you
may also need one or more of the following:</para>
<itemizedlist>
<listitem><para><emphasis>Obsolete Net
Install:</emphasis>
<filename>chrproot.tar.gz</filename></para>
</listitem>
<listitem><para><emphasis>Obsolete HD
Install:</emphasis>
<filename>chrproot.tar.gz</filename>,
<filename>hdinstall.lha</filename></para>
</listitem>
</itemizedlist>
<sect2><title>Hacked Installation (Obsolete)</title>
<para>First you will have to install a base system, so you
will be able to boot &linapus; from the hard disk instead of
from the ram disk - giving you more flexibility and tools to
install applications. You can do this in one of two ways.</para>
<sect3 id="hdinstall"><title>From Hard Disk</title>
<para><emphasis>Text and script by Sven
Ottemann</emphasis></para>
<para>Unpack the archive:</para>
<screen>
lha x hdinstall.lha </screen>
<para>Boot the precompiled kernel, using the ram disk as
root.</para>
<para>Log in as root (with an empty password) and execute
these commands:</para>
<screen>
mount -t affs /dev/your_ados_partition /mnt
sh /mnt/hdinstall </screen>
<para><emphasis>your_ados_partition</emphasis> is the disk
partition where the script is located. On a SCSI disk
"HD0:" this would be "/dev/sda1" and on an IDE disk it
would be "/dev/hda1". This presumes you are using the
first partition on the first hard disk in the chain;
increase numbers for next partition (HD1: = /dev/sda2) and
"increase" letters for next disk (/dev/sdb1). The files
from the <filename>hdinstall.lha</filename> archive should
be in the root of this drive (i.e., not hidden away in
some subdirectory).</para>
<para><emphasis>path</emphasis> is the path to where the
<command>hdinstall</command> script is located.</para>
<para>See further down for details about the questions asked
by the script.</para>
</sect3>
<sect3 id="fromnet"><title>From Net</title>
<para>The generic &linppc; net installation (see <ulink
url="http://www.linuxppc.org/help/install_help/PReP/network_install.cgi">
www.linuxppc.org/help/install_help/PReP/network_install.cgi</ulink>)
can fortunately be used without too much hassle under
&linapus;.</para>
<para>This used to be the only way to install the minimal
system before the <command>hdinstall</command> script was
made. If you're not a true warrior, the hdinstall method
is probably the smartest way of installing a system - and
it doesn't require an extra &linux; box as this method
does.</para>
<para>I didn't scare you off? OK, then you should read the
documentation (see link above). A few hints: put the
chrproot archive on the slave box (remains compressed),
write IP stuff down and generally follow your hacker
instincts.</para>
<para>Boot the precompiled kernel, using the ram disk as
root.</para>
<para>Log in as root (with an empty password) and execute this
instruction:</para>
<screen>
crdisk-net </screen>
<para>Now the script should be running. It's pretty simple
to use; you are asked a handful of questions and when done
(if you passed the test :) it will install the files from
the minimal file system archive on your new root
partition.</para>
<para> The things to be careful about are:</para>
<itemizedlist>
<listitem><para> When the disk partition program is
started: quit it. You should already have prepared the
partitions under &ados;.</para>
</listitem>
<listitem><para> Options for
<application>mke2fs</application>: you might want 1kB
blocks.</para>
</listitem>
<listitem><para> When the script asks for install disk:
replace with hda/hdb/sda/sdb as appropriate. See
<filename>kernel-options.txt</filename> for help on
the device names.</para>
</listitem>
<listitem><para> When the script asks for the root and
swap partitions: enter the right partitions.</para>
</listitem>
</itemizedlist>
<para>When you have installed this minimal system, you are
ready to install packages.</para>
</sect3>
<sect3><title>Installing Packages</title>
<para>When you have installed the minimal system, reset the
machine (the hard way) and reboot the kernel, but replace
the <emphasis>/dev/ram/</emphasis> part of
<emphasis>root=/dev/ram</emphasis> with whatever device
you installed the root system to (e.g., /dev/hdb1). This
will boot &linapus; using the hard disk as boot
device.</para>
<para>Mount a drive with the &rpm; packages. Install them in
alphabetic order by using a small rune like:</para>
<screen>
for f in `ls /path/*.rpm`;do rpm -ivh --force --nodeps $f;done </screen>
<para>If you are a bit more on the exotic side, it can also
be done via FTP. First make a list of package names you
want to install, then do:</para>
<screen>
for f in `cat list`;do rpm -ivh --force --nodeps ftp://ftp:foobar@ip-address/path/$f;done </screen>
<para>where <emphasis>ip-address</emphasis> and
<emphasis>path</emphasis> must be replaced with whatever
is appropriate for your system.</para>
</sect3>
</sect2>
</sect1>
</chapter>
<chapter><title>Debugging</title>
<sect1 id="debug"><title>Kernel Debugging</title>
<para>The kernel contains bugs. Period. Fact of life. Some are
just small annoyances, others are show stoppers. Bugs in the
latter category are usually (and fortunately) easy to track
down given enough information.</para>
<para>In this section I will try to explain what you need to
report when you find a bug so it is easier for others to fix
it. If you feel like looking into the problem yourself (please
do!) this may be used as a brief guide of what to look
for.</para>
<sect2><title>Interactive Debugging</title>
<para>Newer kernels contain a stub which makes it possible to
debug the kernel in &gdb; via a serial line from another
&linux; host. This is <emphasis>the</emphasis> way to debug
something since you have access to registers and memory
while the system is still alive - or at the time of its
death.</para>
<para>[Unfortunately, I don't know if this interface is
working properly. I hope to get it tested RSN. I will add
some more text about it when I know more.]</para>
</sect2>
<sect2><title>Non-interactive Debugging</title>
<para>Sometimes interactive debugging is not an option and you
have to rely on <function>printk</function> calls. Basically
you insert some <function>printk</function>s with different
texts in places of the kernel where you suspect there is a
problem.</para>
<para>You can ouput variable values and thereby check that the
values are what you expect them to be. Output strings
throughout the flow of a function to check that it executes
the expected if-statements, does the correct number of
iterations or to get an idea of where it hangs. Use your
imagination and be generous - each time you decide to insert
more <function>printk</function>s you have to rebuild the
kernel and reboot; you might as well put in plenty to start
with.</para>
<para>Debugging <filename>head.S</filename> is a bit more
tricky. I use a handful of serial-print assembly routines by
Roman Zippel. These can be found in the file
<filename>arch/ppc/kernel/debug.h</filename> - include it
from <filename>head.S</filename>, call
<function>initserial</function> from somewhere in the top of
the code and use the other functions to output
characters/values where you want to investigate
something. You must use functions <function>foo</function>
when memory mapping is disabled and functions
<function>foo2</function> when memory mapping is
enabled.</para>
<sect3><title>Debug Options</title>
<para>The text from the <function>printk</function>s go to
the console. Sometimes it makes sense to output the text
to memory so you can save it for later reference or
analysis. Use <option>debug=mem</option> as an option to
bootstrap when booting and after reseting, run &dmesg;
(from <xref linkend="sd-misc">) under &ados;. It should
find the text.</para>
<para>You can also use the option <option>debug=ser</option>
which will output the text over the builtin serial line at
9600 baud.</para>
</sect3>
<sect3><title>Standard Debug Output</title>
<para>If a user application causes an exception it will be
terminated without affecting any other application
running. However, if the kernel causes an exception there
is no way of handling it gracefully. In those situations
the kernel will dump some information on the console which
may help developers track the problem down. It may look
like this:</para>
<screen>
NIP: C00D4EA4 XER: 00000000 LR: C00D6E64 REGS: c3c83bd0 TRAP: 0700 MSR:
00089972 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c3c82000[130] 'mingetty' mm->pgd c2856000 Last syscall: 4 last math
00000000
GPR00: 00000000 C3C83CC0 C3C82000 C02C2FC0 00000002 00000000 00000019 00000050
GPR08: 00000000 C01528B4 C02C2FC0 00000000 3004E158 0024BB94 C017C6E0 C017C6E0
GPR16: C3EAC000 00000002 C0150000 C01704F8 00000001 00000000 00000000 C3C83D8A
GPR24: 00203578 C3F5C4A0 00000001 00000000 C02C30D4 00000000 000007D0 00000000
Call backtrace:
C004D580 C00D6E64 C00D7C94 C00D8710 C00CA630 C00CC4F4 C00C7988
C0026818 C000447C 00201570 00201D18 002010B8
Kernel panic: Exception in kernel pc c00d4ea4 signal 4
Rebooting in 180 seconds.. </screen>
<para> The NIP (next instruction pointer) tells what
instruction caused the exception and the contents of the
other registers can help explain why. The call backtrace
shows the call sequence resulting in the exception
allowing you to examine those functions (in the source
code) and possibly insert a breakpoint (&gdb;) or
<function>printk</function>s to help track down the
problem.</para>
<para>However, since these addresses are specific to the
kernel you are running, a dump like the above is not
necessarily of much help to kernel hackers. In order to
help them you need to use the tool
<application>ksymoops</application> (source found in the
<filename class=directory>scripts</filename> directory of
the kernel sources) which will use the
<filename>System.map</filename> file to produce a more
usable dump you can send to the kernel list.</para>
<para>When you have found out which function the exception
was caused by (look up the address in the
<filename>System.map</filename> file) you might be able to
make a quick fix. If the function belongs to a driver that
is not properly supported you can disable it when doing
<command>make config</command>. If the driver accepts
kernel options you might want to use some other options
than the default or the ones you used when the exception
occurred.</para>
</sect3>
<sect3><title>Other Helpful Information</title>
<para>The exception you experience may be caused by many
things. Kernel hackers <emphasis>may</emphasis> have an
idea of what is most likely to be the culprit. You can
help them narrow down the list of potential problems by
including the following information:</para>
<itemizedlist>
<listitem><para> The bootstrap line you use to start the
kernel (so we can see what options you used).</para>
</listitem>
<listitem><para> The output from bootstrap when using the
<option>-d</option> option (so we can see what
configuration you have).</para>
</listitem>
<listitem><para> The kernel debug output (use
<option>debug=mem</option> and &dmesg; as described
earlier).</para>
</listitem>
<listitem><para> If you need to do something in particular
to cause the exception, tell us so we can try to
reproduce it.</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>
</chapter>
</part>
</book>